Discussion :

[mister3957]

Bonjour à tous,

J'aimerai implémenter un système de listener.

Prenons un simple exemple:
J'ai une fenetre avec un champ text "nom:". Lorsque l'utilisateur modifie ce champ, ça modifie une valeur dans le gestionnaire de configuration. Un truc comme ConfigManager::GetInstance()->GetUserNameProperty()->SetValue(txtNom.value());

Seulement, la fenêtre écoute cette propriété pour mettre à jour son contenu si jamais les données de configuration changent. Mais en se mettant à jour, elle va redéfinir la valeur de la propriété (puisqu'elle ne fait pas la différence entre un changement de valeur de ses controles suite à une action de l'utilisateur ou un "rafraichissement" provoqué par une valeur qui a changé...

Il y a donc redondance.

Y'a une astuce pour palier à ce problème?

Je vous remercie

A bientôt

[Aurelien.Regat-Barrel]

elle va redéfinir la valeur de la propriété (puisqu'elle ne fait pas la différence entre un changement de valeur de ses controles suite à une action de l'utilisateur ou un "rafraichissement" provoqué par une valeur qui a changé...

faire la différence...

tu programmes avec quoi ?

[mister3957]

Salut Aurélien,

Je programe avec wxWidgets pour l'IHM..

Mais j'ai bien réfléchit sur ma conception et je pense faire ça:

J'aurai un objet Command avec dedant une methode Execute() et Undo() et aussi un pointeur void* vers l'objet qui a créé la commande et un booléen qui spécifie si l'apelant dois être notifié des changements effectué sur chaquer property que modifiera la commande.
Biensûr cette méthode est abstraite, et les commandes l'implémenterons et redéfinierons les méthodes Execute() et Undo(). Normalement, la liste des commandes se résume à modifier une property, ou ajouter/supprimer un item dans une property.
Parmis ces commandes, y'en aura une qui s'appellera CommandList, qui sera une liste de commandes (utile pour après).

Ensuite j'aurai une autre classe abstraite CommandManager qui prendra des commandes, et effectuera des opérations dessus. Les CommandManager peuvent être par exemple LogManager, ExecuteManager, SocketManager, etc... Et encore une fois, une classe dérivée CommandManagerList qui sera une liste de CommandManager (histoire d'nvoyer les commandes à un seul objet, et brancher/débrancher des gestionnaires de commandes facilement).

Les property prendront le pointeur vers l'acteur ainsi que le booléen pour savoir si le créateur de la commande doit être notifé. Chaque property aura biensûr sa liste d'écouteur ou d'adapteur (pas encore spécifié qui aura quoi). Et elles pourront comparer si l'écouteur est l'appelant et si il faut le notifier lui aussi.

Je pense faire une classe Event histoire de toujours devoir être obligé de spécifier le créateur de la modification et s'il faut le notifier, ça c'est secondaire. En fait, je vais faire une property particulière: la PropertyList, qui sera une liste de property et qui écoutera chaque property de sa liste. Lorsque la property notify un évennements, il faut qu'ille spécifie l'acteur car il n'est pas forcément branché sur la property, mais sur la liste qui la contient, et c'est elle qui dira "non toi t'es l'apelant et tu m'as dit qu'il fallait pas te le notifier, alors j'te dit rien". C'est pour ne pas avoir à brancher un écouteur sur chacune des property qu'il doit écouter, comme ça je peux grouper. Par exemple, au lieu de se brancher sur le UserNameProperty et le UserPassProperty, je ferai une UserProperties qui contiendra les deux et je me brancherai sur la liste... Puis si on ajoute une property, pas besoin de modifier les écouteur.

Ha oui, chaque property aura un nom, pas forcément obligatoire ni unique, mais c'est pour aider les écouteurs à trier, c'est optionnel.

Car si j'ai bien pigé le concept de classe, l'utilisateur exécute une action via l'ihm, l'ihm met à jour les objet metier, et les objets metier notifie l'ihm qu'ils ont évolué, et celle-ci se met à jour... Plutôt que on met direct l'ihm à jour.
Pour une champs texte c'est pas la peine, mais pour une liste qu'on ajoute /retire un item via des boutons...

Et au final, le code ressemblera à ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
// Cas de modification d'un champ texte (par exemple l'identifiant utilisateur)
ChangeStringCommand* command = new ChangeStringCommand(this, ConfigManager::GetInstance()->GetUserName(), champ->GetText(), false);
CommandManager::GetInstance()->PostCommand(command);
// le champ texte est la source de modification et de donnée finale, donc pas besoin de récup l'evennement de changement puisque c'est sa valeur la référence de la nouvelle valeur de la property, c'est pour ça que y'a false ça la fin
 
//Cas d'ajout d'une personne dans une liste
AddItemCommand* command = new AddItemCommand(this, ConfigManager::GetPersonnes(), item, true);
// ici on met true, car il faut etre notifié de l'ajout de l'item (ça se peut que ça ne soit pas fait, par exemple s'il existe déjà dans l'objet metier).

Bon voilà, ça me semble assez modulaire et générique (je dois encore regarder les templates, j'en ai jamais fait, mais ça pourrai être util).

J'espère que je n'ai rien oublié dans tout ça...
Qu'en pense-tu?

Merci

A bientôt

[mister3957]

Ha oui, j'ai oublié un truc...

Le CommandList, c'est une liste de commande à remplir et exécuter d'un coup. Car pour un UndoManager, il se peut qu'une action à la vue de l'utilisateur soit en fait un cumul de plusieurs actions internes. Du coup il ne verra qu'il seul commande: la commande list.

Et aussi, chaque comande aura un libellé, pour l'afficher dans un menu de l'ihm (Annuler modifer prenom).