Discussion :

[rp37000]

Bonjour,

Je souhaiterais savoir comment vous procédez habituellement pour passer d'une vue à une autre.
Par exemple on est dans la vue1, laquelle contient un Bouton1 censé ouvrir une autre fenêtre : la vue2.

Comment gérez-vous cela?


Moi j'ai commencé comme suit mais je me retrouve bloqué!!


Dans le main() je commence par:

IModele modele=new modeleConcret();
//Avec modeleConcret implémentant IModele

IVue vue1=new vueConcrete();
//Avec vueConcrete implémentant IVue

IController controleur1=new controllerConcret( vue1, modele );
//Avec controllerConcret implémentant IController



Ensuite dans le constructeur controllerConcret( IVue vue, IModele modele) j'ai:

this.modele=modele;
this.vue=vue;
this.vue.setController(this); //< Une IVue attend pour controller un IController


//----------

Quand l'utilisateur cliquera sur le fameux Bouton1 de la vue1, alors le contrôleur controleur1 en sera informé et alors là : je ne sais pas ce que doit faire ce contrôleur dés lors.... pour que la vue2 soit ouverte et associée à un autre contrôleur controller2 ??? Je suis coincé je ne sais pas!

- Qui doit instancier la vue2 ?
- Qui doit instancier le contrôleur pour cette dernière?


Sachant qu'idéalement je souhaiterais au final avoir des instanciations de la forme:
IVueBis vue2=new vueConcreteBis();
IControllerBis controleur2=new controllerConcretBis( vue2, modele );

Mais où écrire ça?
Qui est censé connaître l'interface IVueBis et la classe vueConcreteBis?
Qui est censé connaître l'interface IControllerBis et la classe controllerConcretBis ?


Si vous aviez des réponses, des solutions, ou si vous voulez bien me faire part de vos pratiques habituelles ça me serait d'un grand secours....!


Merci à tous et toutes.

[rp37000]

J'essaye de trouver une solution pendant ce temps, et j'ai une 1ère idée
(je ne sais pas ce qu'elle vaut en terme de MVC-respect)!

Ma première idée est donc de transmettre à chaque Vue (susceptible de mener vers une ou plusieurs autres Vues), des objets Vues (implémentant une interface donnée) qui sont des objets qu'elle saura alors "Ouvrir". La Vue en question
saura donc, sous ordre de son CONTROLEUR , ouvrir l'une des Vues censée lui faire suite. Par contre ce serait le CONTROLEUR , via l'interface CONTROLEUR->Vue, qui ordonnerait à la Vue d'ouvrir telle ou telle vue censée lui succéder.
Un truc du genre:

Le CONTROLEUR dirait à sa Vue this.vue:
this.Vue.showVueXXX();

Et la Vue dans sa méthode showVueXXX() ferait un:
this.vueXXX.open();

vueXXX n'étant connue que par la Vue, laquelle l'a reçue en param. de son constructeur.
Ce qui veut dire que le CONTROLEUR ne connaîtrait pas du tout le type abstrait ou concret de l'objet vueXXX, et qu'il sait juste ordonner à la Vue de l'ouvrir.
L'inconvénient: ça suppose que l'objet vueXXX a été instancié, et initialisé(son Contrôleur,...) avant d'être passée au constructeur de la Vue.
Et il en va de même pour les éventuelles vues qui pourraient succéder à la vueXXX...., etc...


ou qcch comme ça!?
Qu'en pensez-vous??


Auriez-vous d'autres idées, des critiques ?

[tristan_m]

Rebonjour,

J'ai peur de ne pas saisir la problématique en fait ni pourquoi tu as besoin d'avoir simultanément deux vues et deux contrôleurs.

En tout cas, avec les éléments à ma disposition, l'idée immédiate et de faire construire la nouvelle vue et le nouveau controleur au contrôleur1.

Qui mieux que lui sait quelle action effectuer en cas d'évènement?


Donc en gros au moment du clic, vue1 envoie l'évènement au contrôleur1, qui s'occupe de coder les lignes que tu as écrites :

Code :

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

1
2
IVueBis vue2=new vueConcreteBis();
IControllerBis controleur2=new controllerConcretBis( vue2, modele );

Eventuellement il demande une mise à jour au modèle pour prendre en compte le fait que la deuxième vue a été ajoutée.

En tout cas, pour moi ce n'est pas la vue qui doit savoir quelle nouvelle vue doit être créée.
En principe une vue doit juste représenter le modèle. Si le modèle implique la création d'une nouvelle fenêtre alors cette nouvelle fenêtre doit faire partie de la même vue que la première.
En revanche le contrôleur peut décider qu'une vue peut être plus adéquate qu'une autre.


Bref j'ai l'impression de passer à côté de contraintes évidentes mais je n'arrive pas à voir lesquelles

[rp37000]

Bonjour tristan_m,


J'accuse réception de ton point de vue, et t'en remercie.

Je vais te répondre ... prochainement.

Merci encore.

[rp37000]

En fait,

Ce que je veux faire c'est:
Sur la Vue1, par exemple j'ai la liste des clients, je peux en en sélectionnant
un, puis cliquant sur le Bouton "Modifier" (le fameux Bouton1), modifier sa fiche. Cette fiche est ma fameuse Vue2 (pour moi il s'agira d'une autre fenêtre).
Lorsque s'ouvre cette fiche, cette fenêtre donc, je veux que la Vue1 se ferme, puis lorsque l'utilisateur fera "Annuler" ou "Valider" sur cette fiche, ce soit à nouveau la Vue1 qui soit affichée, et que la Vue2 soit fermée.

Voilà pour l'objectif.
Alors selon MVC ça donnerait quoi?

***************************
Toi, tristan_m, tu me proposes en gros que:
Le Bouton "Modifier" de la Vue1 informe le Contrôleur de la Vue1 lorsqu'il est cliqué. Le Contrôleur interroge alors la Vue1 pour vérifier si en parallèle un client est bien sélectionné dans la liste.
Si oui, alors tu suggères que le Contrôleur récupère le client en question et fasse:

IVueFicheClient vue2=new vueFicheClient();
IControllerFicheClient controleur2=
new controllerFicheCLient( vue2, this.modele );

Puis on communique aussi à ce contrôleur-ci les infos concernant le Client
sélectionné.

C'est bien ça??

Ce qui me dérange, dans un premier temps, dans cette façon de procéder, c'est que:

Le Contrôleur initial (celui de la Vue1), disons de type IControllerListeClients, DOIVENT connaître le type CONCRET! : et de la FicheClient, et du Controleur Fiche Client. Donc GROS couplage, ça me plaît pas du tout...
Je souhaite que les seuls types connus par le Contrôleur soient des types Interfaces. Donc je ne veux pas qu'un Contrôleur puisse faire
new Vue() ou new Controller() (types Concrets!) , MAIS que,
soit transmis au Contrôleur de la Vue1(Liste Clients): la Vue2 (de type IVueFicheCLient)(qui elle, connaît son propre Contrôleur à savoir elle sait qu'il est de type IControllerFicheClient, et le possède déjà parmi ses attributs).
Et là je rejoins donc le message que j'ai posté ici le 22/12/2008 à 17h41, à ceci près que cette fois je suis d'accord avec toi: c'est le contrôleur de la Vue1 qui lance DIRECTEMENT l'ouverture de la Vue2 (et non plus le Contrôleur de la Vue1 qui demande à sa Vue1 d'ouvrir sa Vue2).
(En même temps je voudrais aussi éviter de passer par une fabrique abstraite de Vues...: CA EXLUE DONC QU'UN CONTROLEUR CREE UNE VUE, via fabrique ou non(new...).)---> Par contre ça m'oblige à faire un new de toutes les vues
dans le programme principal (main()): et ça niveau mémoire ça pue!!!

Est-ce-que mon problème est plus clair maintenant?

[Patriarch24]

En utilisant le pattern commande, tu peux arriver à tes fins :
- le bouton est cliqué sur la vue 1
- l'évènement remonte au contrôleur, lequel peut alors déléguer cet objet (la commande) à un délégué de traitement
- le délégué de traitement crée la vue concrète (cela dépend de son paramétrage, une fabrique abstraite peut aider) et la retourne au contrôleur
- le contrôleur affiche la vue

En Java, les boutons se voient assigner des actions, avec un nom. Cela peut suffire dans le cadre du pattern commande, mais dans ton cas tu souhaites faire passer une information supplémentaire (le nom du client). Donc dans ce cas, le contrôleur au lieu de faire suivre l'objet commande (event) initial, construit la commande lui-même avec les données qu'il connaît, et fait passer cet objet à son délégué. Et le tour est joué !

[tristan_m]

Bonjour,

J'ai un peu regardé le pattern commande, mais étant donné que je n'en suis pas très familier, j'avoue ne pas avoir saisi comment le délégué de traitement peut connaître le type de la vue concrète
Ou alors il y a un délégué de traitement par type de vue, auquel cas, le contrôleur, à défaut de devoir connaître la vue concrète à ouvrir, doit connaître le délégué "concret"?

Bref je suis un peu perdu

En revanche je note que tu ne passes pas par un contrôleur2, je suis d'accord avec ça.


Personnellement, sur ce problème j'ai un point de vue qui ne va sûrement pas plaire à rp37000

Les vues doivent avoir une interface commune pour pouvoir être interchangeables. Hors là, pour avoir une vue2 qui ne lit qu'un client, je ne vois pas comment faire sans ajouter un paramètre supplémentaire quelque part. Donc avoir une interface différente pour la vue1 et la vue2.
(Ou alors ajouter ce paramètre dans tous les cas mais bon...)

Dans mon esprit, une vue basique est une vue qui représente l'intégralité du modèle. En gros on pourrait imaginer une fenêtre géante avec tous les clients et toutes les valeurs associées affichés et modifiables (c'est théorique hein ).

Maintenant si tu veux une interface plus ergonomique avec plusieurs fenêtres etc..., rien n'empêche de le faire mais dans ce cas là c'est uniquement la vue qui est modifiée. Il n'y a pas de raison que le contrôleur soit impacté.
Donc pour moi, toutes tes fenêtres font partie d'une unique vue, et c'est cette vue qui décide quelles fenêtres doivent être affichées à un instant t (c'est ce dernier point qui ne va pas plaire je pense ).
En l'occurrence, la fenêtre1 ouvre la fenêtre2 sans demander son avis au contrôleur.
Le contrôleur se contente de recevoir les requêtes quelle qu'en soit la provenance.



Je tiens à préciser qu'il est tout à fait possible d'avoir une vue qui n'affiche qu'une (petite) partie du modèle, la seule contrainte étant celle citée plus haut : elle doit s'aligner sur l'interface commune.


Voilà, la soution de Patriarch24 est peut être plus adéquate/simple/facile à mettre en oeuvre que la mienne, il faudra que je revois un peu le pattern commande

Bon courage!

[Patriarch24]

Ou alors il y a un délégué de traitement par type de vue, auquel cas, le contrôleur, à défaut de devoir connaître la vue concrète à ouvrir, doit connaître le délégué "concret"?

Il s'agit bêtement du pattern fabrique abstraite . Le contrôleur n'a qu'un lien vers des interfaces (IView, IViewCreator par exemple), les objets étant créés via une fabrique abstraite.
J'en profite pour glisser un avertissement : attention à ne pas être trop généraliste dans la définition des interfaces IView et IModel, dans une application, à moins de vouloir créer un framework...

[rp37000]

Patriarch24,

Concernant le Pattern Commande, je vois bien ce que tu veux dire,
qqch comme:
this.ObjetCommandeConcret.executer();
avec this: le Contrôleur, et ObjetCommandeConcret instance passée au constructeur du contrôleur, et dont le type concret implémente une interface ICommand (méthode executer()).
Pour la transmission de l'ID du client sélectionné dans la Vue1(liste des clients) vers la Vue2 (fiche Client) : j'ai une idée différente de la tienne
CAR je NE veux PAS que le Contrôleur instancie (new...) quoique soit!
Ceci car je veux rester souple et assez général... (sans vouloir non plus faire un framework).


Bon, voici un premier Diagramme de classes(généraliste, soit, mais bon je préfère TOUJOURS), dans ce diagramme je ne fais volontairement pas apparaître le modele, pour ne pas encombrer...

->Pour l'instant:

-Ce premier diagramme est SANS FABRIQUE ABSTRAITE:
Donc un de mes problèmes (qui était de ne pas créer les instances des Vues avant qu'elles ne doivent être affichées), n'est pas résolu car sur ce diagramme, comme on peut le constater: le constructeur de la classe concrète cde_openFiche, reçoit en param. une instance de Vue (de type IVue_fiche). Un objet cde_openFiche est un objet commande qui encapsule
une Vue de type IVue_fiche, et lance l'ouverture de celle-ci dans sa méthode executer(). Sachant qu'avant d'appeler executer() il faudra positionner via la méthode setID(int ID) de l'objet commande en question, l'attribut ID de l'objet commande qui n'est rien d'autre que l'ID (ID client par exemple) à transmettre à la Vue IVue_fiche au moment de l'appel de sa méthode
open(int ID). (cf. commentaires du Diagramme).


Mais en même temps, je trouve que ce diagramme n'apporte rien d'intéressant (peut-être parce-que il ne contient pas de fabrique abstraite) car on aurait pu faire tout aussi bien la même chose sans passer par le pattern commande. -->(cf. second Diagramme).

Tristan_m, je vais bien réfléchir a ce que tu dis, et je reviens vers toi.

[rp37000]

Dans ce premier Diagramme (comme signalé plus haut, je ne fais volontairement pas apparaître le modèle).


L'idée est que la prochaine Vue à ouvrir soit encapsulée dans un objet Commande, implémentant l'interface ICommand, à savoir la méthode executer().


Sur la Vue1(liste des clients), lorsqu'un Client est sélectionné et que l'utilisateur clique sur le Bouton Modifier, alors cette Vue1 (de type IVue_liste)
en informe son Contrôleur (de type IController_liste), via la méthode modifFiche() de ce dernier.
Ce contrôleur demande alors l'ID du client à la Vue1 (méthode getID()), puis s'il est OK, le transmet à l'objet Commande(de type ICde_openFiche), via la méthode setID() de ce dernier.
On notera que l'objet commande en question a été transmis en param. au constructeur du Contrôleur en question.


Donc voici la méthode modifFiche() du Contrôleur de la Vue1:

void modifFiche() //Appelée suite à clic sur Bouton Modifier de la Vue1 (this.vue)
{
//this.vue est de type IVue_liste, et this.cde est de type ICde_openFiche.

int ID=this.vue.getID(); //Récup. ID client auprès de la Vue1
if (ID>0)
{
this.cde.setID(ID); //Complète l'objet commande à lancer: transmet l'ID pour la Vue2
this.cde.executer(); //Lance la commande: à savoir ouvrir une Vue2 de type IVue_fiche.

//L'IDEAL serait d'ailleurs que la Vue1 (this.vue) soit fermée à cet endroit-ci.
}
}

Le reste est sur le Diagramme.


Bon voilà je ne trouve pas que ça apporte grand chose puisque comme on peut le voir sur le second Diagramme, on peut en faire autant sans utiliser le Pattern Commande.
Et qui plus est, un problème persiste: on doit instancier au préalable la
Vue2 (de type IVue_fiche) avant de la transmettre au constructeur de l'objet commande.
(Ce dernier étant ensuite à transmettre au constructeur d'un Contrôleur de type IController_liste).

[rp37000]

Dans ce SECOND Diagramme (comme signalé plus haut, je ne fais volontairement pas apparaître le modèle).


L'idée est que la Vue(Vue2: fiche client) devant succéder à la Vue1(liste des clients) soit un attribut de la Vue1.
La Vue1 ferait alors un this.Vue2.open(ID) au moment voulu.

A la rigueur, on peut imaginer le scénario suivant:
Dans la liste des clients (Vue1, de type IVue_liste), lorsqu'un client est sélectionné et que l'on clique sur le Bouton Modifier, alors la Vue1 informe son Contrôleur (de type IController_liste) de ce clic.
Celui-ci lui dit: OK(ou pas) tu peux ouvrir la Vue qui doit te succéder.
Il lui dit par un: this.vue.openFiche().
Et dans openFiche() de la Vue1, celle-ci fait un: this.vueFiche.open( this.getID() ).
Avec vueFiche instance (de type abstrait IVue_Fiche) passée au constructeur
de la Vue1.


-Ca donnerait donc la Vue1 (type IVue_liste):

void openFiche()
{
this.vueFiche.open( this.getID() );
}


-Et dans le Contrôleur de la Vue1 (de type IController_liste) on aurait la méthode:

void modifFiche() //Appelée suite à clic sur Bouton Modifier de la Vue1 (this.vue)
{
//this.vue est de type IVue_liste

int ID=this.vue.getID(); //Récup. ID client auprès de la Vue1 pour vérifier si >0
if (ID>0)
{
this.vue.openFiche(); //Dit à la this.vue d'ouvrir sa fiche.
//L'IDEAL serait d'ailleurs que la Vue1 (this.vue) soit fermée à cet endroit-ci.
}
}

Le reste est sur le Diagramme.


Un problème persiste toujours: on doit instancier au préalable la Vue2 (de type IVue_fiche) avant de la transmettre au constructeur de la Vue1 (de type IVue_liste).



Une solution consisterait peut-être à instancier au moment voulu, la Vue2, dans la méthode modifFiche() du Contrôleur de la Vue1:
via des objets fabriqueAbstraite passés au constructeur de ce dernier.
IVue_fiche vueFiche=this.fabriqueVueFiche.getInstance();
IController_fiche =this.fabriqueControllerFiche.getInstance( vueFiche );
vueFiche.open( this.vue.getID() ). //Avec this: contrôleur de la Vue1 (this.vue).
??
Mais le problème dans cette façon de faire: c'est qu'il faut dans ce cas alourdir avec 2 hiérarchies supplémentaires de fabrique!

[rp37000]

Tristan_m,

Ces 2 Diagrammes et les commentaires ci-dessus, devraient pouvoir servir de retour aux visions que tu exposes.
Perso. je penche plus vers le second Diagramme, bien qu'il me faille instancier
mes Vues à l'avance.




En attendant je ne sais toujours pas comment faire pour créer mes Vues (Vue2 (la Fiche)) à la volée, et sans que le contrôleur (de la Vue1)
fasse de new, et SI POSSIBLE sans fabrique!

PS: je voudrais également un Contrôleur par Vue.

- Il est exigeant le p'tit...


Merci pour tous vos efforts!

[tristan_m]

Bonjour,

Personnellement j'ai une vision très monolithique des différents composants M, V et C.
Chacun doit avoir une et une seule interface, à laquelle doivent se conformer les deux autres.
Implémenter un contrôleur avec plusieurs classes spécialisées est évidemment recommandé, mais dans ce cas là je privilégierais un pattern façade, plutôt qu'un système "inter-multi-MVC" où chacun des sous composants va communiquer avec un ou plusieurs des autres sous composants directement.

Ça permet certes de découpler clairement les différents aspects de l'application, mais le jour où on décide que finalement la tache X sera effectuée par le sous contrôleur lambda2 au lieu du sous contrôleur lambda1, il faudra alors modifier les sous-vue en conséquence...

Soit les aspects sont totalement dissociés, auquel cas on peut créer plusieurs MVC différents qui ne communiqueront pas entre eux (voire plusieurs applications différentes).
Soit ils sont mêlés entre eux, auquel cas il faut faire attention à ce que le changement complet de telle ou telle partie n'impacte pas le reste.
Donc typiquement ne pas avoir à savoir dans une vue qu'il y a un sous contrôleur qui possède telle ou telle méthode alors que l'autre ne les possède pas etc...

Donc je reste sur mon idée de départ, bien qu'à contre sens des autres avis :
La fenêtre liste et la fenêtre fiche sont toutes les deux ouvertes par la vue sans demander l'avis du contrôleur. Après rien n'empêche d'avoir des classes séparées au sein du contrôleur pour gérer spécifiquement telle ou telle requête venant de la vue et rien n'empêche non plus d'avoir des classes spécifiques dans la vue pour gérer telle ou telle fenêtre.

Voilà, en tout cas c'est comme ça que je ferais. J'avoue en même temps ne pas avoir les idées très claires sur le fonctionnement des solutions avec des commandes et des fabriques abstraites .

[rp37000]

Bonjour tristan_m , et merci d'avoir exposé ta position et les arguments qui vont avec.

Tu dis:
"Donc typiquement ne pas avoir à savoir dans une vue qu'il y a un sous contrôleur qui possède telle ou telle méthode alors que l'autre ne les possède pas etc..."
Je trouve ça plus que vrai. Effectivement ce qui revient à dire "vive les interfaces", dans l'exemple que je donne notamment , l'interface IController.

Tu dis:
"...mais le jour où on décide que finalement la tache X sera effectuée par le sous contrôleur lambda2 au lieu du sous contrôleur lambda1, il faudra alors modifier les sous-vue en conséquence."
Je ne comprends pas pourquoi tu dis cela, car justement: si les Contrôleurs
lambda1 et lambda2 IMPLEMENTENT la même interface IController:
PAS DE PROBLEME ---> la tâche X est implémentée dans les 2 aux yeux de toute Vue. Ou sinon je n'ai pas compris ce que tu veux dire... !


Quoiqu'il en soit tristan_m le SECOND Diagramme de classes que j'expose couvre ce que tu dis , à savoir:

C'est la Vue vue_liste (vue1) elle-même qui Ouvre la vueFiche (vue2) qui lui succédera.
Et la particularité sur ce second de Diagramme, c'est que c'est le Contrôleur de la vue_liste qui ORDONNE à celle-ci, par un this.vue.openFiche(); , d'ouvrir la Vue vueFiche qui lui succède:
et en effet le Contrôleur de la vue_liste NE CONNAIT PAS DU TOUT la vueFiche (seule la vue_liste la connaît). Le Contrôleur de la vue_liste sait juste ORDONNER par un appel de méthode this.vue.openFiche(); , à sa vue de se DEBROUILLER pour ouvrir sa prochaine Vue vueFiche.
En fait au final, la vue_liste aura une méthode openFiche() qui fera
this.vueFiche.open(....); .
Es-tu d'accord avec moi que la solution avec le Second Diagramme rejoint ton idée?


Sinon pour le pattern Commande: laisse tomber par rapport à ce problème-ci de Vues.
Si tu veux:
Je viens de créer pour l'occasion, une discussion sur le Pattern Command uniquement, où j'essaie d'expliquer simplement de quoi il s'agit, etc... avec un exemple simple.
http://www.developpez.net/forums/d66...r/#post3905681

[PanicKernel]

Bonjour,

Personnellement je développe des IHM MVC dans mon entreprise depuis deux ans et j'ai remarqué que premièrement chacun exploite et comprend le pattern MVC d'une manière différente.

En ce qui concerne ma vision actuelle et l'emploi que j'en fais suite aux évolutions des applis sur lesquels j'ai travaillé, il en ressort que :

- le problème d'instancier par le controleur des vues concrète n'est pas vraiment un problème sauf si vous élaborez un framework. Sinon il n'y a que peu de chance que la technologie d'affichage de votre appli change avant une refonte complète. Je préfère donc rester pragmatique et instancier directement mes vues depuis le controleur. S'il venait à avoir besoin d'abstraire la vue ou le controleur, un coup de refactoring ne prend pas tant de temps que ça et le tour est joué.

- j'ai pris l'habitude de travailler par domaine fonctionnelle qui sont ensuite découpés en plusieurs pôles MVC réutilisables dans d'autres domaines (que j'abstrais en fonction de la réutilisabilité). Cela donne des structures arborescentes des modèles et des controleurs.

Enfin typiquement pour ton problème d'ouverture de fenêtre je procèderai simplement comme ça :
1. la vue liste ne connait pas la vue fiche;
2. le controleur de liste a un controleur de fiche (relation unidirectionnelle);
3. le modèle est le même (ie : une liste + l'élement en cours de modif dans la vue fiche), les deux vues sont abonnées sur ce modèle;
4. quand on clique sur le bouton d'édition dans la vue fiche on appelle le controleur de liste qui délègue l'action au controleur de fiche
5. le controleur de fiche instancie la vue fiche (lui passe sa référence et celle du modèle)
6. à la validation de la fiche, le controleur fiche demande au modèle la mise à jour des données et ferme la vue fiche;
7. la vue liste est automatiquent mise à jour par le modèle.

Je sais que je ne respecte pas tous les principes de MVC, mais au moins on sépare les données des ihms (le modèle ne connait pas les vues ni les controleurs). La navigation est gérée par le controleur, les vues sont indépendantes de la cinématique et reflète les données du modèle.

[rp37000]

Bonjour PanicKernel,

Merci beaucoup pour ta réponse, concrète, très claire et développée.
Elle va en effet bien me servir comme base pour penser à
des solutions plus personnelles. Il me manque encore de la pratique pour aboutir à des modèles plus abstraits, comme je le souhaite, mais ça viendra.

Encore merci PanicKernel,
il est clair que ta solution tient tout à fait la route en l'état.