QSignalTransition : propager les paramètres du trigger vers la classe métier
Voilà je voulais avoir vos avis sur la façon de construire une transition (QSignalTransition)
Contexte :
J’ai une classe Metier qui contient :
- Les états QState
- La machine,
- Les transitions
- une fonction qui construit le graphe d’états
- Les fonctions “métier” exécutées lors des transitions ou dans l’entrée d’un état.
J’ai une interface qui communique avec la classe métier notamment via un signal ‘état(val)’.
J’ai dans mon modèle une transition qui prend pour trigger, le signal ‘état(val)’, et pour action une fonction qui prend ‘val’ comme paramètre.
Qt propose de réimplémenter QAbstractTransition::onTransition(QEvent) pour coder l’action. Seulement cette fonction s’exécute dans l’espace de la transition et non dans la classe métier.
Le signal QAbstractTransition::triggered() ne propage pas -hélas- l’évènement.
Donc comment attaquer proprement la classe métier depuis la transition ?
La solution de la ‘callback C’
Subclasser QSignalTransition, pour founir un accesseur sur le parent et la fonction à exécuter.
Ca marche mais pour être générique il faut que :
tous les parents aient un seul type de base (QObject *)
La signature de la fonction est unique (donc on utiliserait une QList<QVariant>) pour être le plus générique possible.
Utiliser un accesseur
Le trigger n’envoir plus d’information. La classe métier se connecte au signal triggered et utilise un accesseur sur l’interface. Gros problème : si l’objet métier et l’interface s’exécute de façon asynchrone. Il faut alors installer un mécanisme de synchronisation pour assurer l’intégrité des informations, et plus de choses encore si l’on veut éviter une perte d’information.
La réémission d’un signal triggered()
Pour être générique et éviter l’implémentation en pagaille de signaux/slot, il faudrait émettre un signal avec QList<QVariant>avec en arguments les valeurs envoyés par le trigger. Il pourrait être émit en place du signal triggered().
C’est ma solution préférée, car finalement on ne fait que propager l’évènement vers le récepteur.
Seulement triggered() étant un signal je reimplemente onTransition() pour envoyer un autre signal triggered(QList<QVariant>) auxquel je connecterais un slot de la classe métier.
Revoir la modélisation
Etudié mais pas possible de faire autrement. :roll:
S'il le faut le placerai du code.
Merci pour toute réponse.
