Application wxPython, héritage

BH wrote:

Bonjour,

Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.

Quels sont les intérêts et inconvénients des deux approches ?

Merci

""" ...séparer du programme .... Hériter la class "interface" .... """:
c'est un peu antinomique non ? dès que tu hérites, tu dois importer ... et
de ce fait lier ta "logique" à l'IHM ... et ça c'est pas bon du tout.

Personellement je te conseille le principe inverse à celui qu'on t'a
préconisé: passe tes objets "applicatifs" à ton IHM ... mais jamais, au
grand jamais, ne lie les deux.

Si dans certain cas de figure (ça m'énerve mais ça m'arrive
régulièrement ... Mais chu mauvais) tu as besoin (par exemple: depuis un
timer) de faire péter une boîte de dialogue depuis ta "logique" ... alors
crée un couche IHM_To_APP à base de callback pour gérer ça.

A tord ou à raison c'est ce que je fais depuis quelques temps.

hg

Bonjour,

Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".

Je suppose que par classe "interface", tu veux dire la partie GUI ?

On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.

Quels sont les intérêts et inconvénients des deux approches ?

<HS>
Tel que tu le décris, ça prête trop à confusion pour donner une réponse
simple.

Dans l'absolu, il est évidemment préférable de séparer la logique
applicative de la logique de présentation. L'intérêt est bien évidemment
que ça rend la logique applicative indépendante de la présentation, donc:
* aisément testable
* (au moins théoriquement) réutilisable.

Après, la façon de s'y prendre dépend du type d'appli.

Un pattern courant sous Unix est d'avoir une appli en ligne de commande
avec une quantité invraisemblables d'options, et d'écrire une appli GUI
qui se contente de construire la ligne de commande d'après les choix de
l'utilisateur (et éventuellement de présenter les résultats). Dans ce
cas de figure, la séparation entre logique applicative et GUI est on ne
peut plus claire, puisqu'il s'agit de deux applis différentes !-)

Une autre solution est de concevoir la logique applicative sous forme de
bibliothèque, puis de développer une (ou des) interface(s) utilisateur
utilisant cette bibliothèque. Il est évident que ça ne peut fonctionner
que si la partie présentation ne gère que et exclusivement que la
présentation, et se contente pour le reste d'appeler la bibliothèque.

En tout état de cause, je te recommande de faire une petite recherche
sur "MVC".

Quant à celui qui te conseille de faire "hériter la classe programme de
la class interface", soit on a des définitions très différentes de "la
classe programme" (que je comprend comme étant "la logique
applicative"), soit je ne veux en aucun cas de lui sur un de mes projets.
</HS>

A part ça, tu a une question sur Python ?-)

Le concept de bibliothèque et d'interface me plaît plus que génerer des
lignes de commandes. Même si je suis un Linuxien pratiquant.

Merci pour toutes ces explications.

Bonjour,

Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".

Je suppose que par classe "interface", tu veux dire la partie GUI ?

On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.

Quels sont les intérêts et inconvénients des deux approches ?

<HS>
Tel que tu le décris, ça prête trop à confusion pour donner une réponse
simple.

Dans l'absolu, il est évidemment préférable de séparer la logique
applicative de la logique de présentation. L'intérêt est bien évidemment
que ça rend la logique applicative indépendante de la présentation, donc:
* aisément testable
* (au moins théoriquement) réutilisable.

Après, la façon de s'y prendre dépend du type d'appli.

Un pattern courant sous Unix est d'avoir une appli en ligne de commande
avec une quantité invraisemblables d'options, et d'écrire une appli GUI
qui se contente de construire la ligne de commande d'après les choix de
l'utilisateur (et éventuellement de présenter les résultats). Dans ce
cas de figure, la séparation entre logique applicative et GUI est on ne
peut plus claire, puisqu'il s'agit de deux applis différentes !-)

Une autre solution est de concevoir la logique applicative sous forme de
bibliothèque, puis de développer une (ou des) interface(s) utilisateur
utilisant cette bibliothèque. Il est évident que ça ne peut fonctionner
que si la partie présentation ne gère que et exclusivement que la
présentation, et se contente pour le reste d'appeler la bibliothèque.

En tout état de cause, je te recommande de faire une petite recherche
sur "MVC".

Quant à celui qui te conseille de faire "hériter la classe programme de
la class interface", soit on a des définitions très différentes de "la
classe programme" (que je comprend comme étant "la logique
applicative"), soit je ne veux en aucun cas de lui sur un de mes projets.
</HS>

A part ça, tu a une question sur Python ?-)

J'aurais juste une demande, si vous aviez un exemple de programme où
l'application est bien distincte de son interface graphique.

Merci encore.

Bonjour,

Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".

Je suppose que par classe "interface", tu veux dire la partie GUI ?

On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.

Quels sont les intérêts et inconvénients des deux approches ?

<HS>
Tel que tu le décris, ça prête trop à confusion pour donner une réponse
simple.

Dans l'absolu, il est évidemment préférable de séparer la logique
applicative de la logique de présentation. L'intérêt est bien évidemment
que ça rend la logique applicative indépendante de la présentation, donc:
* aisément testable
* (au moins théoriquement) réutilisable.

Après, la façon de s'y prendre dépend du type d'appli.

Un pattern courant sous Unix est d'avoir une appli en ligne de commande
avec une quantité invraisemblables d'options, et d'écrire une appli GUI
qui se contente de construire la ligne de commande d'après les choix de
l'utilisateur (et éventuellement de présenter les résultats). Dans ce
cas de figure, la séparation entre logique applicative et GUI est on ne
peut plus claire, puisqu'il s'agit de deux applis différentes !-)

Une autre solution est de concevoir la logique applicative sous forme de
bibliothèque, puis de développer une (ou des) interface(s) utilisateur
utilisant cette bibliothèque. Il est évident que ça ne peut fonctionner
que si la partie présentation ne gère que et exclusivement que la
présentation, et se contente pour le reste d'appeler la bibliothèque.

En tout état de cause, je te recommande de faire une petite recherche
sur "MVC".

Quant à celui qui te conseille de faire "hériter la classe programme de
la class interface", soit on a des définitions très différentes de "la
classe programme" (que je comprend comme étant "la logique
applicative"), soit je ne veux en aucun cas de lui sur un de mes projets.
</HS>

A part ça, tu a une question sur Python ?-)

Le concept de bibliothèque et d'interface me plaît plus que génerer des
lignes de commandes.

L'un n'empêche pas l'autre.

Historiquement, la ligne de commande précède le GUI - et dans la
pratique, on est assuré qu'elle soit toujours disponible. Il est donc
normal que pas mal de programmes unix soient d'abord développés en ligne
de commande.

Maintenant, si tu a effectivement bien séparé la logique applicative de
l'interface utilisateur, tu peux (théoriquement) proposer tout type
d'interfaces (CLI, GUI, web...).

(hs : si tu pouvais éviter de top-poster, ça serait pas mal...)

J'aurais juste une demande, si vous aviez un exemple de programme où
l'application est bien distincte de son interface graphique.

X-CD-Roast (et la plupart des cd-burners sous Nunux)

Sinon, google "GUI frontend", tu devrais trouver du monde...

(hs : si tu pouvais éviter de top-poster, ça serait pas mal...)

J'aurais juste une demande, si vous aviez un exemple de programme où
l'application est bien distincte de son interface graphique.

X-CD-Roast (et la plupart des cd-burners sous Nunux)

Sinon, google "GUI frontend", tu devrais trouver du monde...



Ok, Merci !

BH wrote:

BH wrote:

Bonjour,

Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.

Quels sont les intérêts et inconvénients des deux approches ?

Merci

""" ...séparer du programme .... Hériter la class "interface" .... """:
c'est un peu antinomique non ? dès que tu hérites, tu dois importer ...
et de ce fait lier ta "logique" à l'IHM ... et ça c'est pas bon du tout.

Personellement je te conseille le principe inverse à celui qu'on t'a
préconisé: passe tes objets "applicatifs" à ton IHM ... mais jamais, au
grand jamais, ne lie les deux.

Si dans certain cas de figure (ça m'énerve mais ça m'arrive
régulièrement ... Mais chu mauvais) tu as besoin (par exemple: depuis un
timer) de faire péter une boîte de dialogue depuis ta "logique" ... alors
crée un couche IHM_To_APP à base de callback pour gérer ça.

A tord ou à raison c'est ce que je fais depuis quelques temps.

hg

Merci de tes information. Concernant Python, mon problème vient du fait
que les méthodes déclenchées par les bind sont dans la classe IHM pour
l'immense majorité des exemples que j'ai trouvé sur Internet.

Je n'arrive pas à comprendre comment séparer suffisament bien la logique
applicative de la logique interface pour concevoir mon appli dans les
règles de l'art.

Je bosse en ce moment sur un TPE.

Ma classe principale est une classe IHM (Frame) - elle crée au démarrage la
plupart des objets "logiques" dont elle a besoin (transaction_reseau,
transaction_carte_a_puce, compatbilité, skins ....)

Tous les binds sont dans cette classe.

Les problèmes commencent quand je dois gérer des évènements externe
asynchrones ou longs (+ d'une seconde).

Dans le premier cas, le problème principal est que si l'évènement n'arrive
pas, je dois garder le contrôle de mon IHM:

"""Insérez la carte du client ou pressez "annuler" """

Là j'utilise en général un wxTimer ... et ne dois pas oublier d'appeler
self.Refresh à la fin ... en plus mon client veut que chaque bouton
transactionnel (ex: débit) reste enfoncé jusqu'à la fin de la
transaction ... je dois donc re-dessiner la bitmap moi-même.


Dans le deuxième cas (ex: transfer des transactions de la journée au
back-office) ... l'objet appelé par la classe IHM (dans l'évènement bind)
lance lui même un "thread" car sinon, là aussi je perds le contrôle de
l'IHM.


Dans certains cas (ceux qui m'énervent), je passe "self" à mon
objet "logique", pour qu'il puisse appeler une call-back IHM si besoin
est ... mais cette callback aura toujours une interface propriétaire car si
je dois un jour passer sur une autre librairie graphique, je ne veux pas
avoir à modifier mes modules "logiques"


J'espère que ça aide.


hg






j'utilise en général un timer dans la classe IHM (wx.Timer) car je dois

BH wrote:

Bonjour,

Je souhaite concevoir une application avec une interface wxPython.
Mais il faudrais bien séparer du programme la classe "interface" de la
classe "programme".
On m'a conseillé de faire hériter la classe programme de la classe
interface plutôt que de passer l'objet programme à l'objet interface
interface.

Quels sont les intérêts et inconvénients des deux approches ?

Merci

""" ...séparer du programme .... Hériter la class "interface" .... """:
c'est un peu antinomique non ? dès que tu hérites, tu dois importer ... et
de ce fait lier ta "logique" à l'IHM ... et ça c'est pas bon du tout.

Personellement je te conseille le principe inverse à celui qu'on t'a
préconisé: passe tes objets "applicatifs" à ton IHM ... mais jamais, au
grand jamais, ne lie les deux.

Si dans certain cas de figure (ça m'énerve mais ça m'arrive
régulièrement ... Mais chu mauvais) tu as besoin (par exemple: depuis un
timer) de faire péter une boîte de dialogue depuis ta "logique" ... alors
crée un couche IHM_To_APP à base de callback pour gérer ça.

A tord ou à raison c'est ce que je fais depuis quelques temps.

hg

Merci de tes information. Concernant Python, mon problème vient du fait
que les méthodes déclenchées par les bind sont dans la classe IHM pour
l'immense majorité des exemples que j'ai trouvé sur Internet.

Je n'arrive pas à comprendre comment séparer suffisament bien la logique
applicative de la logique interface pour concevoir mon appli dans les
règles de l'art.

(snip conseils de bon sens)

Merci de tes information. Concernant Python, mon problème vient du fait
que les méthodes déclenchées par les bind sont dans la classe IHM pour
l'immense majorité des exemples que j'ai trouvé sur Internet.

Jusque là, c'est normal. Les classes de l'IHM définissent les vues et
controleurs (qui sont nécessairement assez intimement liés).

Je n'arrive pas à comprendre comment séparer suffisament bien la logique
applicative de la logique interface pour concevoir mon appli dans les
règles de l'art.

Les gestionnaires d'évènement (ie -> "les méthodes déclenchées par les
bind") appelent les fonctions/méthodes de la partie applicative - et
accessoirement gèrent ce qui doit l'être de la logique de présentation
au passage (à moins que tu n'implémentes un vrai MVC, dans lequel c'est
la partie applicative - le modèle - qui notifie les vues d'une mise à
jour, via un pattern Observer).