Discussion :

[yanis97]

Bonjour;

J'ai une IHM en Swing qui communique avec un controleur via ListenerAction pour déclencher les actions. J'ai séparé ds 2 packages différent l'iHM elle même avec le controleur.
L'iHM est dans un package à part et je souhaite rattaché la classe controleur qui implémente la classe ActionListener dans le package service (la ou il y'a le traitement des actions).
mais j'ai un import circulaire :

- IHM doit faire un import du controleur pour appeller “actionPerformed” du controleur
- Le Controller doit faire un import de la vue “Swing IHM” pour envoyer les données qu'elle doit assembler pour les affichées à l'utilsateur.
Pour le moment ça marche : car le controleur est ds le même package que l'ihM mais il faut mieux le sortir ds un autre package (model).

Quelqu'un a t'il une solution ?

Merci;

[spekal]

- IHM doit faire un import du controleur pour appeller “actionPerformed” du controleur

Normalement, non : le contrôleur implemente seulement un ActionListener, et l'IHM ne connait du contrôleur que l'identité ActionListener. Donc l'IHM ne connait pas le contrôleur, seulement le Listener, même si c'est le même objet.

Je sais bien que la réalité est souvent un peu plus compliquée, mais au vue de ce que tu nous dis, tu peux faire comme je te dis

[yanis97]

Salut;

Donc la logique fait également que le le contröleur ne connait pas l'iHM pour lui forwarder des data ?, par consequent il faut une autre interface entre le controleur et l'IHM ?


Merci;

Normalement, non : le contrôleur implemente seulement un ActionListener, et l'IHM ne connait du contrôleur que l'identité ActionListener. Donc l'IHM ne connait pas le contrôleur, seulement le Listener, même si c'est le même objet.

Je sais bien que la réalité est souvent un peu plus compliquée, mais au vue de ce que tu nous dis, tu peux faire comme je te dis

[spekal]

Donc la logique fait également que le le contröleur ne connait pas l'iHM pour lui forwarder des data ?, par consequent il faut une autre interface entre le controleur et l'IHM ?

La logique, peut être. Swing, non.

Le contrôleur - qui est plutôt un écouteur chez swing (Listener) - connaît le contrat (l'interface) que comprend la vue pour alerter d'un événement. La différence listener / contrôleur est importante, parce que la plupart du temps les listeners ne doivent pas modifier ce qu'ils écoutent.

Tu as des tas d'infos très précieuses sur tout ça dans Writing Event Listeners.

Par exemple, soit le plus habituel des écouteurs, le ActionListener. Un contrôleur qui voudrait écouter un bouton va mettre en oeuvre cette interface. Par là, il dépend donc de la GUI, mais seulement au niveau du contrat ; il peut nommer son listener comme il le veut, lui faire faire ce qu'il veut, du moment qu'il implémente ActionListener.

Lorsque le bouton sera cliqué, le bouton consultera la liste de ses écouteurs, mais la seule chose qu'il sait d'eux est que ce sont des ActionListener. De cette façon, il pourra déclencher la méthode actionPerformed. Qui est exactement cet ActionListener, que fait-il dans cette méthode, le bouton n'en sait rien (surtout que, la plupart du temps, le listener est une classe interne package private).

Il y a donc, entre listener et vue, une dépendance au niveau du contrat, mais une indépendance au niveau de la mise en oeuvre.

Et ainsi de suite.

[yanis97]

Bonjour;

OK je suis d'accord avec toi mais la question que j'ai posé c'est dans la'utre sens COntroller => Vue.
C'est comment le controler lorsqu'il recoit le resultat de l'opération (action) par exemple récupérer dans une DB la liste des personnes pour les afficher.
Donc le controller reçoit un arrayList de type d'objet Personne, maintenant il doit transmettre cette liste à la vue pourqu'elle celle-ci l'affiche à l'utilisateur ?
DOnc :

Code :

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

1
2
3
4
5
6
7
8
9
public class Controller implements ActionListener {
.....
private daoPersonne;
public void actionPerformed(ActionEvent e) {
  if e = "Boutton(OK)" alors List pers = daoPersonne.getPersonneList()
 else ...
//comment transmettre la liste "pers" à la vue ?
 
}

Faut'il créer une instance d'une autre interface pour envoyer la liste ?

Merci;

La logique, peut être. Swing, non.

Le contrôleur - qui est plutôt un écouteur chez swing (Listener) - connaît le contrat (l'interface) que comprend la vue pour alerter d'un événement. La différence listener / contrôleur est importante, parce que la plupart du temps les listeners ne doivent pas modifier ce qu'ils écoutent.

Tu as des tas d'infos très précieuses sur tout ça dans Writing Event Listeners.

Par exemple, soit le plus habituel des écouteurs, le ActionListener. Un contrôleur qui voudrait écouter un bouton va mettre en oeuvre cette interface. Par là, il dépend donc de la GUI, mais seulement au niveau du contrat ; il peut nommer son listener comme il le veut, lui faire faire ce qu'il veut, du moment qu'il implémente ActionListener.

Lorsque le bouton sera cliqué, le bouton consultera la liste de ses écouteurs, mais la seule chose qu'il sait d'eux est que ce sont des ActionListener. De cette façon, il pourra déclencher la méthode actionPerformed. Qui est exactement cet ActionListener, que fait-il dans cette méthode, le bouton n'en sait rien (surtout que, la plupart du temps, le listener est une classe interne package private).

Il y a donc, entre listener et vue, une dépendance au niveau du contrat, mais une indépendance au niveau de la mise en oeuvre.

Et ainsi de suite.

[spekal]

//comment transmettre la liste "pers" à la vue ?

Tu le transmets au modèle de ta vue.

Souvent, avec les listes, on utilise une JTable. Les JTable ont leur modèle de données, qui est javax.swing.table.TableModel.

Et souvent, on a pas de JTable, mais tout autre chose ; on utilise alors le modèle de cet autre chose, modèle que l'on peut faire soi-même ; et, quand on est fénéant, on ne fait pas de modèle, mais on envoie directement à la vue.