Conseils pour le Swing Application Framework

Bonjour,

Je m'intéresse au Swing Application Framework, et j'ai lu ça entre autre.

Ce qui me gène est que ce framework semble considérer la partie swing comme étant toute l'appli ; une fois qu'on aurait lancé les composants swing, finalement, on n'aurait plus qu'à attendre le shutdown.

Mais chez moi, dans mes applications, la partie swing n'est qu'une partie ; j'essaie de faire que ce soit seulement le V du MVC ou assimilé. Je ne suis pas un adepte inconditionnel du MVC, mais enfin il y a souvent un peu de ça quand même...

Typiquement quand je lance une appli, je lance d'un coté le modèle, de l'autre la GUI ; je ne lance pas la GUI qui lancerait le modèle... mais peut être que je me trompe ?

Qu'en pensez-vous ?

Même avec un MVC je vois mal ce que tu entends par "lancer le modèle d'un côté et la GUI de l'autre". Le cycle de vie d'une application graphique est principalement conditionné par le cycle de vie de son interface graphique. À mon avis tu te prends trop la tête pour un problème qui n'en est pas un. Et connaissant les mecs qui ont fait le Swing Application Framework, je ne mets pas en doute leurs choix :)

Ouais ben moi je les connais pas, et je ne mets même pas en doute les choix de qui que ce soit, j'essaie juste de comprendre par rapport à ce que je fais et ce que font les autres.

MOA, je dois lancer, d'un coté un réseau, d'un coté une base de données, d'un coté une GUI, d'un coté des périphériques, etc, et tout ce petit monde a ses propres désidératas.

À ce qu'il me semble le cycle de vie de ces applis n'est pas du tout conditionné par la seule GUI. Peut être me prends-je la tête avec des trucs superfétatoires, mais cela m'arrangerait que l'on m'explique, alors.

Je comprends mieux ton cas, mais je ne vois pas en quoi le Swing Application Framework t'empêche de tout lancer à part ?

Ben il ne m'empêche pas... Je me demandais juste si le swing app... prenait en compte toutes ces choses, où s'il se préoccupait seulement du rythme de vie de la GUI.

Mais j'ai de plus en plus l'impression qu'il ne prend en compte que la seule GUI, ce qui est bien dommage... Enfin... c'est déjà ça :roll:

Ah d'accord, de ton premier message je comprenais que le SAF t'empêchait de faire ce que tu voulais. Donc oui, il ne s'occupe que de la GUI.

Note que tu peux surcharger la méthode initialize() de la classe Application pour initialiser d'autres chose que la GUI. De même pour shutdown(). Mais j'ai l'impression que c'est ce que tu n'aimais pas :)

Oui et non ; je trouve que les choses démarrent bien avec ce framework, puisque initialize, shutdown et d'autres sont des mouvements que je retrouve dans mes petites affaires ; je fais pas exactement la même chose, mais il y a une nette parenté, même en mieux, et je pourrais m'adapter.

Les choses se gattent ensuite, puisque tout est fait pour swing, et j'ai l'impression que je passerai mon temps à dire Héo il n'y a pas que Swing dans une appli !

Du coup je vois moins bien l'avantage.

Ce framework est fait pour simplifier la partie Swing d'une appli. Rien de plus. C'est un framework simple et léger que l'on peut apprendre très rapidement. Ce n'est pas NetBeans RCP ou Eclipse RCP. Au moins ce framework te fera gagner du temps pour la parte Swing et la rendra beaucoup plus claire et simple.

J'ai pas encore regarder le SAF , j'ai un peu du mal avec les frameworks.

Mais effectivement normalement dans une bonne architecture ce n'est pas spécialement à une couche de lancer l'autre, car une couche doit pouvoir etre remplacer en live sans tout éteindre; donc on doit pouvoir retirer la couche graphique sans pour autant éteindre un sniffer de réseau par exemple qui logue en base.

Il est interessant d'utiliser un "cerveau applicatif" (le grand superviseur quoi), qui détecte quand une couche est active ou non et gère les synchronisations entre ces dernières. En somme la couche graphique une fois activée devrait emettre un hello I'm here et recevoir un refresh de son model de données, lequel n'est pas forcément celui utiliser par les autres couches mais une adaptation.

Oui oui, on sait comment doit fonctionner une architecture en couches, etc. Les modèles canoniques de conception et les design patterns, c'est beau mais il ne faut pas non plus s'enfermer à tout prix dedans. La véritable question à se poser ici est : l'application doit-elle pouvoir changer d'UI facilement ? Ou encore : l'application a-t-elle un sens sans son UI ?

Compliquer l'application pour le plaisir de suivre un modèle théorique... je ne parle pas de tout mélanger ni de faire quelque chose de sale, mais il faut savoir trouver un juste milieu.

C'est vrai

Citation:

---

Envoyé par Gfx

Oui oui, on sait comment doit fonctionner une architecture en couches, etc. Les modèles canoniques de conception et les design patterns, c'est beau mais il ne faut pas non plus s'enfermer à tout prix dedans. La véritable question à se poser ici est : l'application doit-elle pouvoir changer d'UI facilement ? Ou encore : l'application a-t-elle un sens sans son UI ?

Compliquer l'application pour le plaisir de suivre un modèle théorique... je ne parle pas de tout mélanger ni de faire quelque chose de sale, mais il faut savoir trouver un juste milieu.

---

Mouais... Et le jour où Sun nous pond un JDBCApplicationFramework, on fait quoi ?