organiser le code 2

Version imprimable

27/02/2024, 01h43
Beginner.

organiser le code 2

Salut,

J'ouvre ce fil pour ne pas embrouiller l'autre fil : organiser le code 1

J'aimerais savoir comment vous faites pour organiser votre code dans certaines situations :

Exemple 2 :

Une interface graphique dans laquelle il y a plein d'onglets (frames)...

Chacun d'eux contient des champs de saisi, des boutons...

Pour l'instant j'utilise une class pour chaque onglet...

Il y a par exemple des méthodes qui sont exécutées chaque fois qu'une donnée est saisie (par exemple pour mettre à jour les autres champs)...

Le problème c'est que les class (pour chaque onglet) peuvent dépendre les unes des autres mais que je voudrais quand même séparer le code dans différents fichiers...

Pour l'instant je fais du bricolage pareil que dans l'exemple de l'autre fil...
27/02/2024, 09h41
wiztricks

Citation:

Envoyé par Beginner.

Le problème c'est que les class (pour chaque onglet) peuvent dépendre les unes des autres mais que je voudrais quand même séparer le code dans différents fichiers...

"peuvent dépendre" ne dit rien sur la relation de dépendance... mais effectivement, on ne pourra pas construire cela sans avoir travaillé la relation de dépendance entre classes(*) ou en utilisant des relations clés en main comme le propose Qt avec slots/signaux.
(*) et on est toujours dans de la POO... et l'existence de forums plus adaptés.

- W
27/02/2024, 10h05
Beginner.

Ah il y a une solution avec Qt... C'est donc que cela ne doit pas être aussi simple qu'on pourrait le croire...

Bon ben ça me rassure quelque part...
27/02/2024, 11h18
wiztricks

Techniquement cela réalise un pattern appelé observer comme mentionné dans cet article de wikipédia. Avec Tk, on peut réaliser la même chose en utilisant des Variables (si on veut faire çà côté Tk) où avec des class python.

- W
27/02/2024, 11h44
Beginner.

Il faudra que je regarde ça attentivement mais à première vue cela me fait penser aux Custom Events en JS...
27/02/2024, 11h54
Sve@r

Bonjour

Citation:

Envoyé par Beginner.

Le problème c'est que les class (pour chaque onglet) peuvent dépendre les unes des autres mais que je voudrais quand même séparer le code dans différents fichiers...

Cela ne doit pas être. Chaque onglet a son propre objet et ça c'est bien. Ensuite on peut penser que la saisie/boutons de l'onglet est indépendant de tous les autres donc quand l'utilisateur fait sa saisie, la saisie est validée puis il passe à un autre onglet et idem. Et là ça marche.

Mais on a aussi le droit de dire que la saisie de l'onglet 2 dépend de ce qui a été saisi dans l'onglet 1 (imaginons une saisie un peu complexe donc découpée) et dans ce cas il faut passer par une espèce d'objet de contrôle.
Chaque onglet doit avoir un signal type "saisie terminée" qui est envoyé quand tous les champs qui le concernent sont bien remplis ; et l'objet "contrôle" associe ce signal à un slot chez-lui qui centralise la saisie de l'onglet.
Ensuite quand on passe à l'onglet suivant celui-ci récupère du contrôle les valeurs des autres onglets pour faire sa propre cuisine et etc. Il doit avoir une méthode "onShow()" dans un onglet qui permet de faire une action quand il est appelé. Et l'action c'est donc de récupérer de l'objet de contrôle les éléments dont il a besoin.

Et au final l'objet de contrôle, quand tout a été saisi, s'occupe alors de l'enregistrement de la saisie en bdd.
27/02/2024, 11h55
wiztricks

Citation:

Envoyé par Beginner.

Il faudra que je regarde ça attentivement mais à première vue cela me fait penser aux Custom Events en JS...

Il n'y a rien de très original la dedans... Et ce n'est pas difficile à réaliser avec Python voir par exemple le source d'events sur PyPI.
Mais cela reste une façon parmi d'autre pour relier des objets....
Suivant le cas d'autres méthodes seront plus pertinentes.

- W
27/02/2024, 17h59
Beginner.

Citation:

Envoyé par wiztricks

Il n'y a rien de très original la dedans... Et ce n'est pas difficile à réaliser avec Python voir par exemple le source d'events sur PyPI.

Ah oui cela correspond bien aux Custom Events en JS... Il y a aussi une class dans node.js et même PHP...

Citation:

Envoyé par Sve@r

Mais on a aussi le droit de dire que la saisie de l'onglet 2 dépend de ce qui a été saisi dans l'onglet 1 (imaginons une saisie un peu complexe donc découpée) et dans ce cas il faut passer par une espèce d'objet de contrôle.

Oui c'est plus ce genre de situation et même plus compliqué : la dépendance pourrait aller dans les deux sens...

Citation:

Envoyé par Sve@r

Chaque onglet doit avoir un signal type "saisie terminée" qui est envoyé quand tous les champs qui le concernent sont bien remplis ; et l'objet "contrôle" associe ce signal à un slot chez-lui qui centralise la saisie de l'onglet.
Ensuite quand on passe à l'onglet suivant celui-ci récupère du contrôle les valeurs des autres onglets pour faire sa propre cuisine et etc. Il doit avoir une méthode "onShow()" dans un onglet qui permet de faire une action quand il est appelé. Et l'action c'est donc de récupérer de l'objet de contrôle les éléments dont il a besoin.

Et au final l'objet de contrôle, quand tout a été saisi, s'occupe alors de l'enregistrement de la saisie en bdd.

Oui cela ressemble à ce que j'ai pu faire en JS, il faut que je réfléchisse à la question pour savoir jusqu'où on peut aller avec cette méthode...

Sinon je pense aussi à ce qu'on a vu dans l'autre fil...

Salut,

J'ai aussi vu une autre solution basée sur le principe mentionné par @fred1599 & @Sve@r (passage d'instance en argument) sauf que là la communication se fait dans les deux sens :

classA.py
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 from classB import ClassB class ClassA: def __init__(self, class_b: ClassB): self.ref_to_class_b = class_b self.data_in_classA = "Data in classA" def communicate_to_b(self): print("from ClassA to ClassB:", self.ref_to_class_b.data_in_classB) self.ref_to_class_b.method_in_classB() def method_in_classA(self): print("Method in ClassA")
classB.py
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 from typing import TYPE_CHECKING if TYPE_CHECKING: from classA import ClassA class ClassB: def __init__(self, class_a: "ClassA"): self.ref_to_class_a = class_a self.data_in_classB = "Data in classB" def communicate_to_a(self): print("from ClassB to ClassA:", self.ref_to_class_a.data_in_classA) self.ref_to_class_a.method_in_classA() def method_in_classB(self): print("Method in ClassB")
main.py
Code:

1 2 3 4 5 6 7 8 9 from classA import ClassA from classB import ClassB a = ClassA(None) b = ClassB(a) a.ref_to_class_b = b a.communicate_to_b() # Communication de ClassA à ClassB b.communicate_to_a() # Communication de ClassB à ClassA
---> L’inconvénient que je vois pour l'instant c'est qu'il me semble que cela deviendrait plus compliqué dans le cas où on aurait plus de deux class, plus il y a de class et plus cela devient compliqué...

Pour ce cas j'ai trouvé une autre solution...

PS : cette partie :
Code:

1 2 3 4 from typing import TYPE_CHECKING if TYPE_CHECKING: from classA import ClassA
C'est pour pouvoir indiquer le typage :"ClassA" (cf.ci-dessous) en évitant les imports circulaires...

Sous VS Code j'obtiens une bonne assistance : autocomplétion, re-factoring, go to definition...

Il faut mettre le type en string ("ClassA") :
Code:

1 2 class ClassB: def __init__(self, class_a: "ClassA"):

27/02/2024, 19h03
fred1599

Je pense que le pattern qui se rapproche de ce que tu souhaites est le pattern Observer.
27/02/2024, 19h14
wiztricks

Citation:

Envoyé par Beginner.

L’inconvénient que je vois pour l'instant c'est qu'il me semble que cela deviendrait plus compliqué dans le cas où on aurait plus de deux class, plus il y a de class et plus cela devient compliqué...

C'est une généralisation/extension du pattern observer (dont on a déjà parlé) qui s'appelle publish-subscribe.
Ils donnent en référence la bibliothèque externe pypubsub avec un cas d'utilisation (dans la documentation) qui mérite d'être lue.

- W
27/02/2024, 23h01
papajoker

Citation:

Envoyé par Beginner.

cela deviendrait plus compliqué

Il faudrait déjà savoir quelle est ta véritable demande !

Si tu désires une "super" architecture: il faut déjà vouloir tout jeter (sauf formules mathématiques)
Créer des architectures est un gros savoir : cela demande autant de temps que d'apprendre python (minimum: SOLID et design pattern). Donc vouloir le faire immédiatement sur ton projet en cours n'a pas de sens.
Entre architecture/étude, codage, tests-debug, on arrive souvent à des ordres de grandeur du type 30% / 30% / 30%. Es-tu prêt à grandement retarder (encore ton projet) ? À repartir de zéro ?

Utiliser une bonne architecture, avec les bons principes, c'est un code au départ bien plus compliqué (longuement pensé dès le départ). L'intérêt est surtout pour partager son code avec une équipe (pas ton cas) et pour avoir une maintenance plus simple à long terme (tu comptes encore retravailler sur ton projet dans 1..3 ans ?)

ps: ne pas confondre avec "bien ranger ces fichiers dans une arborescence fichier", cela n'est pas lié au code.

Note: on trouve énormément de documentation sur le web puisque ce sujet est plus lié à la poo que à python et parce que l'objet n'est plus tout jeune.
28/02/2024, 18h32
Beginner.

Salut,

Citation:

Envoyé par fred1599

Je pense que le pattern qui se rapproche de ce que tu souhaites est le pattern Observer.

Citation:

Envoyé par wiztricks

C'est une généralisation/extension du pattern observer (dont on a déjà parlé) qui s'appelle publish-subscribe.
Ils donnent en référence la bibliothèque externe pypubsub avec un cas d'utilisation (dans la documentation) qui mérite d'être lue.

Merci à vous deux. J'ai commencé à regarder, il faut que j’approfondisse... Il me semble que cela ressemble aux slots/signaux déjà évoqués sauf que là ce n'est pas propre à Qt...

Citation:

Envoyé par papajoker

Il faudrait déjà savoir quelle est ta véritable demande !

Ben c'est simple, je pensais même que c'était un problème classique, répandu et auquel beaucoup ont déjà eu à faire...

Comme expliqué au premier message :

On a une interface graphique dans laquelle il y a plein d'onglets (frames) et même des fenêtres enfants...

Chacun d'eux contient des champs de saisi, des boutons...

Il y a par exemple des méthodes qui sont exécutées chaque fois qu'une donnée est saisie, par exemple pour mettre à jour les autres champs, pour tracer les courbes en fonction des nouveaux paramètres...

Le problème c'est que les class (pour chaque onglet) peuvent dépendre les unes des autres mais que je voudrais quand même séparer le code dans différents fichiers...

Alors par exemple on peut saisir des nouveaux paramètres dans l'onglet 1 et alors l'onglet 2 doit être mis à jour automatiquement (question de cohérence). Et cela peut aller dans les deux sens...

Voilà restons sur cet exemple simple alors ma question c'est comment ce problème est résolu en général ?

Parmi vous il doit y en avoir qui ont déjà eu à faire ça ou bien à répondre à quelqu'un qui eu à faire ça, non ? Ou bien ça n'arrive jamais ?

---> Pour l'instant il y a la solution du pattern observer et aussi la solution dont j'ai donné un exemple au message #9 (je ne sais pas ce qu'elle vaut mais j'ai une variante qui me semble meilleure...)

Citation:

Envoyé par papajoker

Si tu désires une "super" architecture: il faut déjà vouloir tout jeter (sauf formules mathématiques)
Créer des architectures est un gros savoir : cela demande autant de temps que d'apprendre python (minimum: SOLID et design pattern). Donc vouloir le faire immédiatement sur ton projet en cours n'a pas de sens.

Non effectivement je ne cherche pas à faire une "super" architecture mais juste à faire ce qui est souvent conseillé, à juste titre selon moi, à savoir organiser/structurer son code (fonctions/class, modules, packages...).

C'est plus facile de s'y retrouver, si j'ai un problème ou si je veux mettre à jour une fonctionnalité, c'est plus facile de trouver le bon module que de chercher la partie du code qui nous intéresse parmi des milliers de ligne contenus dans un seul fichier...

Et il y a aussi la réutilisation des modules dans d'autres projets...

Citation:

Envoyé par papajoker

ps: ne pas confondre avec "bien ranger ces fichiers dans une arborescence fichier", cela n'est pas lié au code.

Oui mais si les codes contenus dans ces fichiers dépendent les uns des autres, il faudra bien faire quelque chose, non ?

Citation:

Envoyé par papajoker

Utiliser une bonne architecture, avec les bons principes, c'est un code au départ bien plus compliqué (longuement pensé dès le départ). L'intérêt est surtout pour partager son code avec une équipe (pas ton cas) et pour avoir une maintenance plus simple à long terme (tu comptes encore retravailler sur ton projet dans 1..3 ans ?)

Oui c'est vrai, je pourrais me passer d'une bonne architecture d'ailleurs comme je disais pour l'instant je bricole comme je peux...

Pour l'instant il y a la solution du pattern observer que j’espère approfondir plus tard et il y a aussi la solution dont j'ai donné un exemple au message #9 , je ne sais pas ce qu'elle vaut mais j'ai une variante qui me semble meilleure et j'aimerais savoir ce que vous en pensez...

Cette "solution" me semble meilleure que l'autre (du message ) surtout dans le cas où on a plus de deux class...

Une chose que j'apprécie c'est que sous VS Code j'obtiens une bonne assistance : autocomplétion, re-factoring, go to definition... Et la coloration syntaxique indique tout de suite si un attribut ou une méthode n'existe pas dans la class...

Voici un exemple avec trois class (la communication peut faire dans tous les sens) :

main.py

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
from classA import ClassA
from classB import ClassB
from classC import ClassC
 
class ClassABC:
 
    def __init__(self):
        self.a = ClassA(self)
        self.b = ClassB(self)
        self.c = ClassC(self)
 
 
abc = ClassABC()
 
abc.a.communicate_to_b()
abc.a.communicate_to_c()
 
abc.b.communicate_to_a()
abc.b.communicate_to_c()
 
abc.c.communicate_to_a()
abc.c.communicate_to_b()

classA.py

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
from typing import TYPE_CHECKING
 
if TYPE_CHECKING:
    from main import ClassABC
 
 
class ClassA:
    def __init__(self, class_abc: "ClassABC"):
        self.class_abc = class_abc
        self.data_in_classA = "Data in classA"
 
    def method_in_classA(self):
        print("Method in ClassA")
 
    def communicate_to_b(self):
        print("\nfrom ClassA to ClassB:", self.class_abc.b.data_in_classB)
        self.class_abc.b.method_in_classB()
 
    def communicate_to_c(self):
        print("\nfrom ClassA to ClassC:", self.class_abc.c.data_in_ClassC)
        self.class_abc.c.method_in_ClassC()

classB.py

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
from typing import TYPE_CHECKING
 
if TYPE_CHECKING:
    from main import ClassABC
 
 
class ClassB:
    def __init__(self, class_abc: "ClassABC"):
        self.class_abc = class_abc
        self.data_in_classB = "Data in classB"
 
    def method_in_classB(self):
        print("Method in ClassB")
 
    def communicate_to_a(self):
        print("\nfrom ClassB to ClassA:", self.class_abc.a.data_in_classA)
        self.class_abc.a.method_in_classA()
 
    def communicate_to_c(self):
        print("\nfrom ClassB to ClassC:", self.class_abc.c.data_in_ClassC)
        self.class_abc.c.method_in_ClassC()

classC.py

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
from typing import TYPE_CHECKING
 
if TYPE_CHECKING:
    from main import ClassABC
 
 
class ClassC:
    def __init__(self, class_abc: "ClassABC"):
        self.class_abc = class_abc
        self.data_in_ClassC = "Data in ClassC"
 
    def method_in_ClassC(self):
        print("Method in ClassC")
 
    def communicate_to_a(self):
        print("\nfrom ClassC to ClassA:", self.class_abc.a.data_in_classA)
        self.class_abc.a.method_in_classA()
 
    def communicate_to_b(self):
        print("\nfrom ClassC to ClassB:", self.class_abc.b.data_in_classB)
        self.class_abc.b.method_in_classB()

Citation:

Envoyé par Beginner.

Alors par exemple on peut saisir des nouveaux paramètres dans l'onglet 1 et alors l'onglet 2 doit être mis à jour automatiquement (question de cohérence). Et cela peut aller dans les deux sens...
Voilà restons sur cet exemple simple alors ma question c'est comment ce problème est résolu en général ?

Parmi vous il doit y en avoir qui ont déjà eu à faire ça ou bien à répondre à quelqu'un qui eu à faire ça, non ? Ou bien ça n'arrive jamais ?

Mais puisque tu ne nous donnes rien de ton code, on n'a aucune idée de ton véritable problème.

Un exemple...
Tu peux créer une structure complexe formulaires pour sauvegarder ton formulaire (utiliser une class perso est la bonne façon !). Dans cette structure, tu peux y mettre tes "Entry" et, éventuellement, si il y a un besoin mettre des StringVar (c'est mon exemple ici)
Ici, l'onglet de résultats ne fait que lire en entrée notre structure complexe qui peut être complètement différente de l'interface graphique (pas dans cet exemple).

Note: il n'y a rien d'objet dans cet exemple :mrgreen: Il faut bien que tu travailles un minimum.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 #!/usr/bin/env python import tkinter as tk from tkinter import ttk from collections import defaultdict root = tk.Tk() root.title("formulaire dans plusieurs onglets") root.geometry("500x200") tabControl = ttk.Notebook(root) tabin = ttk.Frame(tabControl) tabinbis = ttk.Frame(tabControl) tab_result = ttk.Frame(tabControl) tabControl.add(tabin, text ='Entrées 1') tabControl.add(tabinbis, text ='Entrées 2') tabControl.add(tab_result, text ='Résultat') tabControl.pack(expand = 1, fill ="both") # l'app utilise "que" cette structure pour faire le travail (le modèle) formulaires = defaultdict(dict) formulaires["tabin"]["nom"]= tk.StringVar() formulaires["tabin"]["age"]= tk.StringVar() formulaires["tabinbis"]["ville"] = tk.StringVar() formulaires["tabinbis"]["cp"] = tk.StringVar() formulaires["tab_result"]["calcul"] = tk.StringVar() # graphique, ... ttk.Label(tabin, text = "Nom et prénom").grid(row = 0, column = 0) ttk.Label(tabin, text = "Age").grid(row = 1, column = 0) ttk.Entry(tabin, textvariable=formulaires["tabin"]["nom"]).grid(row = 0, column = 1) ttk.Entry(tabin, textvariable=formulaires["tabin"]["age"]).grid(row = 1, column = 1) ttk.Label(tabinbis, text = "Ville").grid(row = 0, column = 0) ttk.Label(tabinbis, text = "Cp").grid(row = 1, column = 0) ttk.Label(tabinbis, text = "voir onglet 1 (nom)").grid(row = 2, column = 0) ttk.Entry(tabinbis, textvariable=formulaires["tabinbis"]["ville"]).grid(row = 0, column = 1) ttk.Entry(tabinbis, textvariable=formulaires["tabinbis"]["cp"]).grid(row = 1, column = 1) ttk.Entry(tabinbis, textvariable=formulaires["tabin"]["nom"]).grid(row = 2, column = 1) tk.Label(tab_result, textvariable=formulaires["tabin"]["nom"]).grid(column=0, row=1, columnspan=2) tk.Label(tab_result, textvariable=formulaires["tabin"]["age"]).grid(column=0, row=2, columnspan=2) tk.Label(tab_result, textvariable=formulaires["tabinbis"]["ville"]).grid(column=0, row=3, columnspan=2) tk.Label(tab_result, textvariable=formulaires["tabinbis"]["cp"]).grid(column=0, row=4, columnspan=2) tk.Label(tab_result, textvariable=formulaires["tab_result"]["calcul"], text="En attente de données...").grid(column=0, row=5, columnspan=2) def on_tab_change(event): #global label_result # juste pour démo tab = event.widget.tab('current')['text'] print("actualiser", tab) if tab == "Résultat": print("Actualisation de cet onglet") print("refaire les calculs pour les afficher dans cet onglet") try: calcul = int(formulaires["tabinbis"]["cp"].get()) * int(formulaires["tabin"]["age"].get()) except ValueError as err: calcul = "manque une entrée ?" + str(err) # NORMALEMENT calcul = Formulaires.generer_resultat() formulaires["tab_result"]["calcul"].set("résultat est ??? " + str(calcul)) else: print("refaire aussi les calculs ? (si ils sont en cache ou sous-calculs)") tabControl.bind('<<NotebookTabChanged>>', on_tab_change) root.mainloop()
En poo, puisque formulaires ne contient que des widget ou StringVar, ce n'est qu'une interface entre ta gui et ta classe métier qui fait les calculs/valide les entrées.

La gui ne connait que l'interface formulaires et le code métier lui aussi ne connait que l'interface formulaires (que la gui soit écrite en poo ou pas ne change rien)
L'interface formulaires n'a qu'une seule responsabilité : assurer un flux dans les 2 sens. Jamais elle ne valide un champ ! elle transmet la demande au "métier" et transmet la réponse à la gui. (donc mon exemple de code en l'état actuel est très très mauvais :P)

28/02/2024, 23h08
Sve@r

Citation:

Envoyé par Beginner.

Alors par exemple on peut saisir des nouveaux paramètres dans l'onglet 1 et alors l'onglet 2 doit être mis à jour automatiquement (question de cohérence). Et cela peut aller dans les deux sens...

Petite subtilité (j'en ai parlé mais je le redis): sous Qt tu as la méthode "showEvent()" automatiquement appelée quand un widget (donc un onglet) s'affiche.
Donc l'onglet 2 tu ne le mets pas à jour quand l'onglet 1 fait sa saisie (faisable mais trop casse c... surtout s'il faut le faire sur 10 onglets) mais quand il est affiché. Et là ce n'est pas pareil.
Donc quand un onglet X s'affiche il va chercher les données enregistrées par les autres onglets.

Citation:

Envoyé par Beginner.

Oui mais si les codes contenus dans ces fichiers dépendent les uns des autres, il faudra bien faire quelque chose, non ?

Un code Y ne dépend pas d'un code X. Un code est fait pour traiter des données. Donc X enregistre les données et Y les traite. Ou Y enregistre les données et X les traite.
Et comme c'est séquentiel (je présume que tu n'es pas en prog parallèle) tout marche parfaitement.
PS: le verbe "enregistrer" est à prendre au sens large (enregistrer dans un fichier, en bdd ou même en RAM)
29/02/2024, 06h37
fred1599
Hello,

@Beginner,

La manière dont tu as développé classA, B et C et ABC ne correspondent pas à un pattern Observer.

Pour modéliser un peu,
1. Tes onglets seront chacun composés d'un observateur (on pourrait même dire que chacun de tes onglets est un observateur). Perso je préfère la composition...
2. Ton interface composée de tes onglets sera également composée d'un notificateur (gestionnaire des observateurs).
3. L'observateur envoi des messages, signaux, ... lors de la mise à jour ou d'un mouvement quelconque de tes onglets (à mon sens, la création d'un observateur pourrait prendre comme paramètre un callback).
4. Le notificateur va notifier l'interface (application) en envoyant tous les messages, signaux, ... écoutés par tes observateurs.
Maintenant j'ai quelques questions,
1. Qu'est-ce qui justifie la création d'une classe par onglet ? (Y a-t-il tellement d'actions liées à un onglet ?)
2. Quels sont les signaux que peuvent bien envoyer un onglet ? (Si peu de complexité dans les messages, signaux, est-ce que ça nécessite un pattern Oberver ?)
29/02/2024, 07h31
papajoker
Citation:

Donc quand un onglet X s'affiche il va chercher les données enregistrées par les autres onglets.

ici c'est un problème de design ui et nous n'avons aucune demande précise @Beginner

Avec mon exemple donné plus haut #15:
- On peut considérer que nous avons un unique formulaire "logique" réparti sur 36 onglets
Le composant logique a en interne une structure du type form["champ_nom"] et une seule méthode self.validate().

- On peut considérer que nous avons un formulaire par onglet (bouton valider dans chaque onglet)
Le composant logique a en interne une structure du type form["onglet_nom"]["champ_nom"] et une méthode self.validate("onglet_nom").

- On peut considérer que nous avons x formulaires par onglet (bouton valider dans chaque "frame")
Le composant logique a en interne une structure du type form["onglet_nom"]["frame_nom"]["champ_nom"] et une méthode self.validate("onglet_nom", "frame_nom").

Donc quel que soit le besoin, la logique/structure de base reste la même.
Et nous pouvons, si besoin et si la gui le permet techniquement, toujours avoir une méthode pour valider un seul champ dans notre composant logique.

Le retour de la méthode "Formulaires".validate() pourrait être du type:
Code:

1 2 3 4 err = formulaire.validate() if err: activer_onglet(err.onglet) dialog_erreur(err.onglet, f"{err.champ} non valide ! {err.message}")
Citation:

est-ce que ça nécessite un pattern Oberver ?

Perso, je pense plus à un problème x y ...
01/03/2024, 11h01
MPython Alaplancha

Bonjour,

Citation:

Envoyé par Beginner.

Ah il y a une solution avec Qt... C'est donc que cela ne doit pas être aussi simple qu'on pourrait le croire...

Bon ben ça me rassure quelque part...

...Avec Kivy, le pattern observer se fait avec classe EventDispatcher .
Perso, je ne l'utilise pas et n'en ai jamais encore éprouvé le besoin . De plus, j'us lu un avis qui mentionnait que l'usage pouvait rendre difficile à détecter et à suivre un bug ...
Est ce vraiment de bonne pratique?

Citation:

Envoyé par zen

Explicit is better than implicit.
01/03/2024, 11h46
wiztricks

Citation:

Envoyé par papajoker

Donc quel que soit le besoin, la logique/structure de base reste la même.

Ce qui n'est pas moins important non plus est de constater qu'on peut aussi y "classer" des bouts dans le Model, d'autres dans Views, ... retrouver le pattern observer dans les Variable TK,... Inutile d'avoir une classification nommée Model/View/... pour n epas y retrouver tout ou partie des rôles/responsabilités de...

Le pouvoir de ces abstractions est d'aider à "penser" ces rôles/responsabilités à l'écriture/lecture d'un code où on va s'appuyer sur les fonctionnalités natives du GUI pour les réaliser "avec" (plutôt qu'à côté).

- W
01/03/2024, 13h39
Sve@r

Citation:

Envoyé par papajoker

ici c'est un problème de design ui et nous n'avons aucune demande précise @Beginner

Ca me semble plutôt naturel de ne mettre à jour l'onglet qu'au moment où tu en as besoin plutôt que de le mettre à jour à d'autres occasions dans lesquelles l'onglet n'est pas utilisé...
01/03/2024, 13h41
papajoker

Si j'ai proposé cette structure, c'est qu'elle tend vers le modèle MVVM. Donc assez simple d'y passer par la suite si le besoin existe (et si techniquement tk n'est pas trop limité ? je connais à peine)
Et, je ne pense pas que Beginner soit encore prêt pour les design patterns. Il cherche surtout une architecture fichiers ; l'indépendance des classes (puisqu'il ne fait pas de tests ?) et autres ne l'intéresse pas encore.

MVVM est classique avec divers gui, par exemple, c'est intégré dans QT mais il nomme les view-model en "model", ce qui porte confusion ; et il n'y a rien pour la liaison viewmodel<->model, et donc souvent le model est intégré par facilité dans le view model par les codeurs.
@Beginner
comprendre l'architecture mvvm c'est en fr et le titre correspond très bien au contenu. (mais pas python)
video "en" mais surtout à voir deux minutes pour les graphiques qui définissent très bien les rôles de ces 3 modules.

Citation:

Envoyé par Sve@r

Ca me semble plutôt naturel de ne mettre à jour l'onglet qu'au moment où tu en as besoin plutôt que de le mettre à jour à d'autres occasions dans lesquelles l'onglet n'est pas utilisé...

C'est ce que j'avais fait dans l'exemple "simple"
Puisque je n'ai aucune idée du type de l'application... Peut-être qu'il existe 36 onglets juste pour éviter un trop grand formulaire avec scrolling ? peut-être qu'il n'a pas compris qu'utiliser 36 onglets n'empêche pas d'avoir qu'un seul "formulaire" ?

Parfois, nous devons découper notre formulaire (avec bouton suivant) et à cette étape intermédiaire, il peut avoir des controles ( voir sauvegardes). Ok ce ne sont pas des onglets.
Parfois, en fonction d'une saisie dans l'onglet 1, il faut mettre à jour le formulaire de l'onglet 2 ? (si "personne" alors, dans onglet 2, le combo est "parler/chanter"). Note: je pense plus à un mauvais design.
Parfois, en fonction d'un changement dans le formulaire, on peut désirer un changement dans le menu, barre de status, avancement d'une jauge.
Et si le calcul final est long, pourquoi pas avec un bouton "mettre à jour" dans chaque onglet, faire un sous-calcul en cache/parallèle.
Parfois, on a un fichier ".conf" par onglet, il est donc normal de les actualiser dans l'onglet.
01/03/2024, 14h51
wiztricks

Citation:

Envoyé par papajoker

Si j'ai proposé cette structure, c'est qu'elle tend vers le modèle MVVM. Donc assez simple d'y passer par la suite si le besoin existe (et si techniquement tk n'est pas trop limité ? je connais à peine)

Tk a ses limites mais pas sur ces sujets.

Citation:

Envoyé par papajoker

Et, je ne pense pas que Beginner soit encore prêt pour les design patterns. Il cherche surtout une architecture fichiers ; l'indépendance des classes (puisqu'il ne fait pas de tests ?) et autres ne l'intéresse pas encore.

Qu'il soit prêt ou pas, il a demandé comment nous faisions et... il est difficile de s'en passer lorsqu'on connaît ces abstractions.

- W
15/03/2024, 18h59
Beginner.
Salut à tous,

Désolé pour le retard et merci pour vos réponses...

Citation:

Envoyé par papajoker

Un exemple...

Merci pour cet exemple, je l'ai testé et effectivement on voit par exemple le champ "nom" qui est mis automatiquement à jour, on voit aussi comment l'onglet "Résultat" à accès à tous les champs des deux premiers onglets...

Et effectivement pour faire ce genre de chose il y a les "variables tkinter"...

Citation:

Envoyé par Sve@r

Petite subtilité (j'en ai parlé mais je le redis): sous Qt tu as la méthode "showEvent()" automatiquement appelée quand un widget (donc un onglet) s'affiche.
Donc l'onglet 2 tu ne le mets pas à jour quand l'onglet 1 fait sa saisie (faisable mais trop casse c... surtout s'il faut le faire sur 10 onglets) mais quand il est affiché. Et là ce n'est pas pareil.
Donc quand un onglet X s'affiche il va chercher les données enregistrées par les autres onglets.

Ok c'est noté. Il me semble que c'est différent dans le code de papajoker, on a par exemple le "nom" que l'on peut modifier à partir du champ présent dans le premier onglet et celui présent dans le deuxième. Si on modifie le nom à partir d'un de ces champs l'autre est mis à jour automatiquement et ce, je pense, même si on n'affiche pas l'onglet en question...

Citation:

Envoyé par fred1599

La manière dont tu as développé classA, B et C et ABC ne correspondent pas à un pattern Observer.

Oui tout-à-fait, je ne cherchais pas à utiliser le pattern Observer... Mais cette solution qui permet la communication entre class m'a bien dépannée...
Citation:
Envoyé par fred1599

Pour modéliser un peu,

Tes onglets seront chacun composés d'un observateur (on pourrait même dire que chacun de tes onglets est un observateur). Perso je préfère la composition...
Ton interface composée de tes onglets sera également composée d'un notificateur (gestionnaire des observateurs).
L'observateur envoi des messages, signaux, ... lors de la mise à jour ou d'un mouvement quelconque de tes onglets (à mon sens, la création d'un observateur pourrait prendre comme paramètre un callback).
Le notificateur va notifier l'interface (application) en envoyant tous les messages, signaux, ... écoutés par tes observateurs.
Merci pour ce modèle, j'y reviendrai je pense quand j'aborderais cette question pattern Observer qui me fait penser aux custom events en js...
Citation:
Envoyé par fred1599

Qu'est-ce qui justifie la création d'une classe par onglet ? (Y a-t-il tellement d'actions liées à un onglet ?)
Ben en fait au début je n’utilisais pas forcément des class mais j'ai trouvé que l'usage des class était plus pratique pour organiser le code mais aussi pour éviter trop de variables globales.

Citation:

Envoyé par fred1599

Quels sont les signaux que peuvent bien envoyer un onglet ? (Si peu de complexité dans les messages, signaux, est-ce que ça nécessite un pattern Oberver ?)

Non effectivement je ne dirais pas qu'un pattern Oberver soit indispensable, la preuve mon programme fonctionne plutôt bien avec la solution que j'ai présentée au message #14... Et apparemment le principe du passage d'instance en argument est utilisé me semble-t-il dans matplotlib...

Citation:

Envoyé par MPython Alaplancha

Bonjour,

...Avec Kivy, le pattern observer se fait avec classe EventDispatcher .
Perso, je ne l'utilise pas et n'en ai jamais encore éprouvé le besoin . De plus, j'us lu un avis qui mentionnait que l'usage pouvait rendre difficile à détecter et à suivre un bug ...
Est ce vraiment de bonne pratique?

Ah ben ça ne m'étonnerait pas que cela ressemble aux custom events en js... Après j'ai quand même l'impression qu'il y a quelques différences avec le pattern Oberver...

Citation:

Envoyé par papajoker

@Beginner
comprendre l'architecture mvvm c'est en fr et le titre correspond très bien au contenu. (mais pas python)
video "en" mais surtout à voir deux minutes pour les graphiques qui définissent très bien les rôles de ces 3 modules.

Merci pour ces liens.
15/03/2024, 19h50
Sve@r

Citation:

Envoyé par Beginner.

Il me semble que c'est différent dans le code de papajoker, on a par exemple le "nom" que l'on peut modifier à partir du champ présent dans le premier onglet et celui présent dans le deuxième.

Oui pourquoi pas. Tout est possible selon ton besoin. Un onglet affichant nom et prénom et un autre nom et adresse. Et la modif de l'un ou de l'autre est répercutée en bdd.

Citation:

Envoyé par Beginner.

Si on modifie le nom à partir d'un de ces champs l'autre est mis à jour automatiquement et ce, je pense, même si on n'affiche pas l'onglet en question...

Là je suis plus mitigé. Comment le prouver ? En affichant l'onglet ? Comme pour la lumière du frigo quand on ouvre la porte pour regarder si la lumière s'éteint...
Mais surtout quel but ? Si l'onglet se met à jour à l'affichage quelque part ça devrait suffire non ?
15/03/2024, 20h05
Beginner.

Citation:

Envoyé par Sve@r

Mais surtout quel but ? Si l'onglet se met à jour à l'affichage quelque part ça devrait suffire non ?

C'était juste pour noter la différence, un simple constat, et non un but à atteindre...

Ceci dit cela pourrait avoir un intérêt dans un autre contexte...

Citation:

Envoyé par Sve@r

Là je suis plus mitigé. Comment le prouver ? En affichant l'onglet ? Comme pour la lumière du frigo quand on ouvre la porte pour regarder si la lumière s'éteint...

Je pense qu'on pourrait le prouver en lisant le champ en question sans afficher l'onglet... Il me semble que c'est la variable tkinter qui met à jour le champ et non le fait d'afficher l'onglet...