Discussion :

[Pekis]

Bonjour,

J'aimerais vous faire part de mon expérience de développement d'un application Python Tkinter suivant le pattern MVP et avec un fichier Excel pour le layout:

La View et le Controller (Un Presenter en réalité) partagent le concept de "widget zone" (WidgetZones), une zone fonctionnelle représentant soit un widget isolé soit un groupe de widgets permettant de remplir une fonction, et à laquelle est adjointe une liste d'événements génériques devant être traités par le Controller.
Il appartient à la View d'utiliser la bibliothèque graphique de son choix et de choisir les widgets réels correspondant à ces widget zones.
Des événements génériques (WidgetEvents) leur sont associés, par exemple LEFT_CLICK, FOCUS_OUT, ... ainsi que l'événement ACTIVATE créé afin de pouvoir exprimer un choix métier via l'interface de l'app, tout en laissant une liberté maximale à la View pour son implémentation:

Par exemple:
- Widget zone "SELECT_FILES", événement générique ACTIVATE, sera par exemple traduit par la View comme un tk.Button (avec command), permettant au Controller d'ouvrir une boîte de dialogue de sélection de fichiers

- Widget zone "DOC_TYPES", événment générique ACTIVATE, sera par exemple traduit par la View commme
* un tk.LabelFrame entourant des tk.Radiobutton (avec command) à choix exclusif
* ou un tk.Label associé à une ttk.Combobox (avec <<ComboboxSelected>>) à choix unique
pour sélectionner un type de document (les différents types étant repris dans une Enum), ce choix étént enregistré par le Controller

- Widget zone "SUFFIX", événement générique FOCUS_OUT, sera par exemple traduit par la View comme un tk.Entry (avec <FocusOut>), le Controller enregistrant la valeur du suffixe à ce moment

- Widget zone "SELECT_FILES_INFO", sans événement, sera par exemple traduit par la View comme un tk.label, pour que le Controller y place le nombre de fichiers sélectionnés

L'association tk.labelFrame/tk.Radiobuttons ou tk.Label/ttk.Combobox permet une sélection avec choix exclusif; pour une sélection à choix multiple, on pourrait imaginer une série de widget zones indépendantes, traduites par la View comme de multiples tk.Checkbuttons indépendants

Les widget zones en widgets sont décrites par la View dans une structure WidgetZoneInfo associée à chaque widet zone et contenant le widget lui-même, le type (tk.Button, tk.Label, ...), la variable tk éventuellement utilisée, des infos sur le Style, le layout, ainsi qu'une liste éventuelle des widgets "enfants" en cas de sélection à choix exclusif (tk.Radiobuttons associés à une widget zone représentée par un tk.LabelFrame, ou une ttk.Combobox associée à une widget zone représentée par un tk.label)

Les éventuels widget "enfants" sont décrits chacun dans une structure ChildWidgetInfo et contenant le widget lui-même, le type (tk.Radiobutton, tk.Combobox), des infos sur le Style, le layout, ...

Les layouts utilisés dans WidgetZoneInfo et ChildWidgetInfo sont extraits automatiquement par l'application au départ d'un fichier Excel permettant d'y dessiner les widgets sur base de leurs dimensions en pourcentages relatifs de la largeur et de la hauteur de la fenêtre de l'application et d'inscrire le nom de la widget zone, ainsi que le type !
Ainsi donc, adieu les grid, pack, pad, pady, sticky, ... souvent très perturbants

Ces structures sont parcourues par l'app et permettent d'adresser au Controller un callback unique avec comme uniques paramètres la widget zone, l'événement générique demandé et l'éventuelle valeur associée. Le Controller effectue ensuite les opérations métier nécessaires (Thread-safe) avec infos sur l'état d'avancement et demande à la View d'afficher les résultats.

Qu'en pensez-vous ?

Merci

[Pekis]