Discussion :

[cheprod]

Bonjour à tous,

Je vais devoir développer une application graphique java de taille "moyenne". Les étapes de développement se présentent ainsi : développement d'un prototype d'ici la fin de l'année, puis d'une version béta et ensuite stabilisation du logiciel. J'aimerais cependant ne pas tout mettre à la poubelle après le prototype, histoire de capitaliser sur les solutions mises en place.

Après pas mal de lecture sur le net (j'ai pas retouché à Swing depuis 2005), je reste sceptique quand au choix d'une solution souple et évolutive pour la partie présentation (pour la partie "middleware", c'est encore un autre problème). J'ai trouvé pas mal de discussion datant de 2006, mais depuis, pas grand chose, j'aimerais donc avoir votre avis à l'heure d'aujourd'hui. Ci-dessous les solutions que j'ai envisagée :

- Solution dite "simple" : Utilisation directe des API d'affichage graphique tels que Swing ou SWT/JFace, voir SwingWT. Léger, peu de contraintes mais je trouve que l'application devient vite ingérable et le code difficilement maintenable surtout lorsque l'application grossie rapidement.

- Utilisation d'un Framework : je n'ai pas trouvé de Framework présentation utilisable directement pour des IHM dites "lourdes". Reste la solution d'en coder un soit même, mais s'il n'est pas mutualisé entre plusieurs applications, j'ai peur que le temps de développement du Framework soit plus important que celui de l'application... Reste la solution d'attendre Java 7 qui devrait résoudre le problème (une date de sortie est-elle annoncée ?).

- Utilisation d'un RCP : Apporte sans doute un grand nombre d'avantages indéniables (composants réutilisable, etc...) mais aussi une lourdeur très importante (par exemple que se passe t-il quand la version du socle du RCP évolue ?)

Si vous deviez construire une application "from scratch" aujourd'hui, vers quel choix vous orienteriez-vous ?

Merci d'avance pour votre aide

[fr1man]

Tu peux très bien partir de rien avec Swing.
Si tu structures bien ton code, je ne vois pas trop le problème.
Tu peux utiliser l'application framework, qui permet de structurer ton application swing et devrait être intégré à la prochaine version de java.

Quand tu dis application moyenne, combien d'"écrans" devrais tu avoir ?

Je bosse sur une application Swing d'une bonne taille et on s'y retrouve pas trop mal.

[CheryBen]

Je suis d'accord avec fr1man, il n'y a pas de problème de maintenabilité si l'architecture est bien faite. Il faut bien séparer les fonctionnalités en composants ou package, et en même temps centraliser tout ce qui peut être réutilisable dans quelques composants "core ou outils".

[cheprod]

Ok pour partir de rien, mais dans ce cas, ne faut-il pas se fixer des règles de "bonnes pratiques" (comme dans tout projet vous me direz) assez strictes sur l'utilisation de swing (règle de hiérarchie entre les écrans, etc...) ? Est-ce que des règles comme celles-ci existeraient-elles déjà "en standard" ?

Sinon pour l'application framework, tu me confirme donc qu'il est déjà disponible sous forme de librairie ?

J'avais développer un petit moteur MVC2 il y a 3 ans de cela en repartant du tutoriel de Tahé mais j'avais l'impression de passé plus de temps à codé le framework que l'appli et cela apportait une certaine lourdeur notamment lorsqu'il s'agissait de manipuler des composants dans des nouveaux conteneurs.

Pour le nombre d'écran, une vingtaine dans le prototype et jusqu'à une soixantaine dans la première version je pense, mais je préfère partir du bon pied dès le début.

Merci pour vos réponses.

[fr1man]

Oui tout à fait, cela existe déjà.
https://appframework.dev.java.net/

Après, il y a aussi les Netbeans RCP, Eclipse RCP, voire Spring RCP.
Mais je ne les ai jamais utilisés.

[sinok]

Pour les frameworks tu as l'ensemble JGoodies Bindings+Validation qui fournit tout de même de quoi développer de façon correcte et bien structurée. De même pour le projet BeanProperties.

Sinon tu peux éventuellement fouiller du coté de Gryffon si tu te sens de toucher à Groovy qui est un framework pour Swing inspirré de Grails.

En version payante tu as le JIDEApplicationFramework qui dans l'ensemble plutôt intéressant et plutôt complet (MVC et tutti quanti), et à 300$ la license c'est vite amorti par le nombre de journées gagnée. Pour se donner une idée des possibilités du bestiau: http://www.jidesoft.com/jdaf/JIDE_De...oper_Guide.pdf

[gifffftane]

Moi je te conseillerais swing + test ; c'est très formateur et structurant.

Au niveau des règles... si tu t'y connais pas en swing, le mieux c'est de ne pas t'en donner au départ, elles viendront avec l'expérience.

De mon coté, certainement que je code comme un cochon, car je serais bien en peine de dire quelles règles j'applique pour swing... je m'en suis donné pour le codage en général, mais pour swing en particulier... rien, ou presque. Les seules que je connaisse sont celles de tout le monde qui code en swing : Utilisez Les Layouts, Faites Gaffe Au EDT... probablement que ça fait un framework dans les salons internationaux...

Je serais plus demandeur de règles de design pour les interfaces homme-machine ; mais là...

[cheprod]

Bonjour et merci bien pour ces réponses

Merci pour toutes ces indications. Je vais commencer à creuser toutes les pistes que vous m'avez fourni... et je reviendrais sans doute avec quelques questions

[eclesia]

de mon point de vue il y deux solutions viables a long terme :

- Appli swing classique. Je conseil ce cas si ton appication est bien spécialisé (et encore) ou disons plutot qu'elle n'a pas un schema classique. Ce que je sous entend c'est la necessité d'avoir un affichage tres "hors-norme" comme on peut en trouver dans l'aviation ou des secteurs scientifiques.

- Appli basé sur une plateforme (je recommande netbeans RCP), le temps de prise en main est assez long je dois l'avouer mais le resultat est d'une qualité supérieur, généralement beaucoup plus modulaires avec des systemes de mise a jours, de traductions et autres.

Pour ce qui est de l'evolution de la plateforme, ce n'est pas trop fastidieux encore, chaque version passe une bonne partie de l'ancien code en @deprecated ce qui permet de faire vivre le projet sur la nouvelle plateforme tout en corrigant progressivement tout les @deprecated.

Si j'avais a choisir maintenant, c'est incontestable une plateforme que je prendrais, toutefois savoir developper en "module" et travailler avec les systemes de class loader demande un niveau d'abstraction en plus. Donc prendre une plateforme quand on debute c'est le meilleur moyen de se prendre la tete et de perdre son temps (et finir dégouté par les plateformes). Il faut mieux attendre d'avoir quelques années de développement java derriere soi pour en tirer le meilleur (conseil de quelqu'un qui s'y est cassé les dents trop tot ).

[cheprod]

Merci pour ta réponse eclesia.

Pour ce qui est de l'utilisation d'un RCP, je pense que je vais oublier pour le moment car mon prototype doit être prêt pour Noël, donc le temps de prise en main risque d'être beaucoup trop court. Je pense donc plutôt partir avec une IHM Swing éventuellement avec l'utilisation de framework (Swing Application Framework, JGoodies ou autres). Pour ce qui est du rendu, je pensais utiliser des composants tel que ceux d'Infonode qui à mon avis apporte un réel plus à l'application.

En fait il ne s'agit pas vraiment d'une IHM "classique" mais d'une IHM à mi-chemin avec un SIG (Système d'Information Géographique) : saisie des données sous forme de JTable et présentation de cartes (projection cartographique de données), courbes, etc... donc au final peu de formulaire de saisie "classique".

J'ai commencé à creuser en début de semaine sur la partie Swing Application Framework. Les lignes directrices semblent très intéressantes mais j'ai l'impression que pour le moment il manque un peu de documentation et de retour d'expérience pour se lancer (à moins que mon anglais moyen me fasse manquer des choses). Je ne m'avance pas trop et je vais décortiquer un peu plus les exemples...

Encore merci pour les avis

[eclesia]

En fait il ne s'agit pas vraiment d'une IHM "classique" mais d'une IHM à mi-chemin avec un SIG (Système d'Information Géographique) : saisie des données sous forme de JTable et présentation de cartes (projection cartographique de données), courbes, etc... donc au final peu de formulaire de saisie "classique".

Hors sujet : Du SIG ? quelle librairie tu utilises ?
(Je travail sur le developpement d'application SIG donc je suis curieux sur le sujet)