Discussion :

[thierryler]

Salut,

Dans mon appli, j'ai une JFrame principale (MainJFrame) qui ouvre une popup (PopupJFrame) dans laquelle l'utilisateur peut saisir les attributs d'un objet. A la fin il clique sur le bouton "valider".

Au clic sur le bouton, je fais des vérifs et tout. Par contre, il faut que j'enregistre tout ça en base. Et là je me demande qui doit faire l'appel. A priori, seule MainJFrame a accès au service correspondant. Mais alors qui déclenche l'action ?

En gros est ce que mon bouton "valider" doit appeler MainJFrame. Ou est ce que le bouton doit lancer un événement et lorsque MainJFrame (qui l'écoute) l'intercepte, c'est MainJFrame qui va chercher tous les champs (ou l'objet déjà tout prêt) dans PopupJFrame ?

C'est quoi le plus propre d'après vous ?

[joel.drigo]

Salut,

Pour moi, le plus "propre", c'est qu'un dialogue de saisie se comporte uniquement comme un producteur/modifieur de "structure", ce qui permet de faire ce qu'on veut de cette structure indépendamment du dialogue (stockage en base, export fichier, etc...), sans rendre dépendant le dialogue des autres traitements.

Ainsi, le processus peut se décrire comme suit

 
data = lire structure ou créer nouvelle structure; 
data = dialogueSaisie(data); // indépendant des processus d'accès à un dao, ou autre (en entrée comme en sortie)
stocker(data); // ou autre (exporter, imprimer, calculs...)

[JoeChip]

En ce qui me concerne, le popup ne concernerait que l'objet à éditer, qui doit savoir comment se mettre à jour dans la DB...

[thierryler]

heu, en fait je ne comprend pas vos réponses. Vous voulez dire que je dois passer le service à ma popup ?

[joel.drigo]

Je voulais dire que, d'après moi, de base, le dialogue ne doit savoir gérer que la structure de données (ce que tu appelles l'objet déjà tout prêt) : ses différentes données, leur validation éventuelle, leur format, type, etc...
Ensuite, que le traitement se fasse par échange de structure entre l'appelant et le dialogue, par évènement( ou par injection d'un handler de traitement, ce qui, fonctionnellement, me semble identique à l'événementiel), etc... concerne, il me semble, un autre débat, concernant des notions de stateful/stateness. Si on veut être stateless, l'injection de handler semble être la plus adaptée, de mon point de vue (Mais est-ce qu'on peut vraiment dire que c'est plus propre ? Je parle plus par expérience que par connaissance de la théorie et de l'art ).

Un truc dans le genre :

 afficher dialogue( data, handler de quoi faire sur valider ) 

Le handler pouvant déléguer directement à ton service. Le handler peut d'ailleurs fournir le support pour déterminer comment continuer après l'action (par exemple, si le service refuse la sauvegarde, on ne ferme pas le dialogue, et on averti l'utilisateur que sa saisie ne peut être validée en l'état, pour telle ou telle raison)

[thierryler]

Heu, je ne suis toujours pas certain de comprendre.

je donne un exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
 
public class MainJFrame extends JFrame  {
 
  // un tableau et son modele pour afficher des donnees
  private JTableModel monModele = ... ; 
  private JTable table = new JTable(monModele);
 
  // Service qui contient le code pour sauver
  private Service mon service; 
 
  // popup
  private PopupJFrame popup = ...;
 
 
  private void methodePourOuvrirLaPopup() {
    // Ici je dois faire quoi ?
 
    popup = new PopupJFrame(...);
    popup.setVisible(true);
  }
}

Et dans la popup :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public class PopupJFrame extends JFrame {
 
  public PopupJFrame(Handler h) {
    // Heu ???
  }
 
  private void clic() {
    // Ici je dois faire un truc avec un handler ?
  }
}

[joel.drigo]

Concrètement, ça pourrait être sous cette forme :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class PopupJFrame extends JFrame {
 
   private IValidateHandler validateHandler;
 
  public PopupJFrame(IData data, IValidateHandler handler) {
    this.validateHandler=handler;
    buildDialog(data);
  }
 
  private void performOk() {
    // Ici je dois faire un truc avec un handler ?
    IData data = getData();
    if ( validateHandler!=null ) {
        IResponse response = validateHandler.validate(data);
        // traitement de response...
    }
  }
 
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
  private void methodePourOuvrirLaPopup() {
    // Ici je dois faire quoi ?
 
   IData data = lire data ... (créer la structure)
 
    popup = new PopupJFrame(data, new IValidateHandler {
         public IResponse validate(IData data) {
 
            try {
                 service.save(data); // exemple
                 return DefaultResponse.OK;
            } catch( ... ) {
                 return new ErrorResponse(...); // par exemple 
            }
        }
 
     });
    popup.setVisible(true);
  }

[thierryler]

Ah ok, donc je passe bien le service (inclus dans le handler) à la popup. En fait, je vais même passer le Jtablemodele, vu qu'il connait le service...

Merci beaucoup.

[joel.drigo]

Le handler, justement, permet de rendre le dialogue non dépendant du service, et, de, surtout, son appel : que tu utilises dans l'implémentation concrète de l'interface de handler, le service directement, le JTableModele, ou les deux, ou autre, ne change justement rien dans la façon de traiter le handler dans le dialogue. Que le service traite les datas en un bloc (un seul argument à la méthode), en plusieurs fois (plusieurs arguments à la méthode), sauvegarde une partie des données d'un coté et une autre de l'autre (plusieurs méthodes), ou fait quoi que ce soit d'autre avec les données, ne concernent pas le dialogue, et peut surtout évoluer sans impact sur le dialogue.

Et si tu as besoin, plus tard, de faire un autre traitement qui utiliserait ce même dialogue, ce sera facile sans nécessairement toucher au dialogue.