Applications desktop: Swing répond-il aux standards actuels?

Bonjour,

Je m'excuse par avance de mes propos qui je suppose pourraient être interprétés comme légèrement trollesques par certains.

Je suis en train de développer une petite interface toute simple en java à l'aide de swing et franchement, je dois dire que cette librairie (que j'ai découverte en 2003) me semble affreusement vieillissante.

Les standards d'aujourd'hui en matière d'interface graphique coté utilisateur impliquent certaines choses, un composant table doit avoir ses colonnes triables et ajustables, un champ de saisie date doit avoir son calendrier lié en popup, les champs de saisie doivent pouvoir être validés simplement. etc...

Pourtant, je tombe assis lorsque je vois les efforts nécessaires pour faire une interface graphique potable en java et le peu de richesse des composants swing. Cela pose un problème de productivité au développeur qui doit par son propre code compenser l'absence de certaines fonctionnalités, et donc passer du temps sur des choses rébarbatives au lieu de pouvoir se concentrer sur les véritables problèmes métier.
Aujourd'hui on n'a plus envie de passer une heure à ajuster la largeur des colonnes de sa jtable et à implémenter des classes de filtrage pour un jfilechooser, à surcharger sa classe avec tout un code dégueulasse pour gérer du tri sur des colonnes. Des exemples parmi de nombreux autres.

On constate peu de progrès avec les années sur cet état des choses, en revanche, du coté des machineries J2EE il y a eu de nombreuses évolutions ces dernières versions. Parfois je me demande si J2SE et Swing ne sont pas tout simplement devenus les parents pauvres dans java.

Enfin pour revenir au sujet, j'en suis même à me demander si le développement d'applications desktop en java n'est pas en train de perdre son sens petit à petit.

C'est pourquoi il existe de nombreuses bibliothèques basées sur Swing et qui font tout ce que tu trouves "dégueulasse", et tu y passes dix secondes au lieu d'une heure.

Et puis si tu attends Java7, tu verras qu'avec les JSR 303 et 296, tu pourras valider tes informations comme tu le souhaites en un tournemain.

Quand bien même, tu compares à Vista et ses gadgets qui en mettent la vue, ou KDE|Gnome ou MacOS, c'est clair qu'il y a du boulot, mais regarde les dates de début de ces projets et l'expérience qu'ils ont. Rome ne s'est pas construite en un jour, tu sais.

Et bien justement, par rapport à ce que tu as dit, j'ai lu le descriptif présent ici:

http://jcp.org/en/jsr/detail?id=295

Ce qu'il dit à la section 2.1 avec le code ciment est exactement ce qui me dérange. Comme quoi c'est pas des défauts que j'invente comme ça pour rigoler.

Citation:

---

C'est pourquoi il existe de nombreuses bibliothèques basées sur Swing et qui font tout ce que tu trouves "dégueulasse", et tu y passes dix secondes au lieu d'une heure.

---

Alors ça m'intéresse, parce que ce que j'ai trouvé jusqu'ici n'a jamais permis d'avoir à la fois des possibilités design-time satisfaisantes (car oui je fais pas des classes graphiques au notepad) et un bon confort utilisateur. Si tu as un nom je suis preneur.

Citation:

---

Quand bien même, tu compares à Vista et ses gadgets qui en mettent la vue, ou KDE|Gnome ou MacOS, c'est clair qu'il y a du boulot, mais regarde les dates de début de ces projets et l'expérience qu'ils ont. Rome ne s'est pas construite en un jour, tu sais.

---

Je pense qu'on doit pas confondre gadget et confort utilisateur, de plus la richesse de l'IHM est quand même en très grand partie ce qui fait que le client final est satisfait ou pas et suivant comment j'irai même jusqu'à dire que c'est ce qui fait qu'on vend son application ou pas.

Bon en ce qui est des tables triables/filtrables, c'est dans java depuis la version 1.6, pour le calendrier tu as JCalendar ou encore la JXMonthView de Swingx.

Pour le coté validation et binding il faut aller voir du coté de JGoodies.

Poour le design diriges toi vers JFormDesigner ou encore netbeans.

Pour avoir un paquet de composants open source bien foutus et utiles tu as les librairies Swingx et JIDE commons. Sans parler des composants proprios (et payants) proposés par JIDE qui sont dans l'ensemble pas mal foutus.

Plus un paquet de L&F qui traînent (Synthetica, A03, Substance ...)

Par contre il est sur que Swing commence à vieillir, et se trouve un poil à l'étroit dans la sacro sainte maxime de la rétro compatibilité. Et puis il ne faut surtout pas se limiter à ce que fourni java de base, sinon c'est vrai qu'on peut en chier.

Effectivement, c'est le genre de post que j'espérai trouver. C'est pas du tout un problème je trouve que de devoir acheter quelques composants si ceux-ci font véritablement économiser en terme de productivité et de maintenance.

Je vais voir pour regarder cela de plus près, sinon pour les Jtable triables en 1.6... euh bien malheureusement j'ai zappé cela on dirait... Sinon j'avais encore bon espoir que les progrès sur le databinding en java nous permette à terme de créer des tables simplement, en créant les colonnes dans le designer et en indiquant simplement la propriété liée, sans passer par l'implémentation du tableModel. Ce genre de chose quoi
Merci

Je veux pas être sec ou quelque chose comme ça, mais généralement, avant de lancer des discussions à nature "trollesques", on se renseigne. ;) Si j'utilise Swing, et que je trouve cette API vieillotte, je vais d'abord voir ce qui existe avant de lancer un troll pareil, ou au moins je demande des informations et parle en connaissance de cause. SwingX est même extrêmement répandu et de nombreuses questions liées à ce sujet sont présentes dans ces forums.

Le DataBinding (que tu as justement corrigé de JSR 296 en 295) arrive à grands pas. Crois bien qu'avec la JSR 303, tu pourras valider des informations directement à partir des annotations, et que le texte contenu dans la JSR 295 ne correspond qu'à la demande bien cadrée de la JSR 295, en considérant ce qui existe et pas les autres JSR proposées. Il y a donc peu de chances que les JSR 303 et 295 ne soient pas fortement liées au final, même si la description actuelle de la demande ne le dit pas.

Citation:

---

Envoyé par _skip

Sinon j'avais encore bon espoir que les progrès sur le databinding en java nous permette à terme de créer des tables simplement, en créant les colonnes dans le designer et en indiquant simplement la propriété liée, sans passer par l'implémentation du tableModel. Ce genre de chose quoi
Merci

---

Bah ca existe, télécharges netbeans, et en créant un projet de type desktop (ou database je ne sais plus) application tu peux parfaitement créer ce genre de choses. Le problème étant que netbeans s'appuie sur les API en cours de développement des JSR 295 et 296.

http://www.contrib.netbeans.org/kb/6...creencast.html

Sinon ces fonctionnalités de binding et validation sont également dans la roadmap de JFormDesigner.

Enfin bon, pour une API datant d'il y a plus de dix ans, Swing a quand même beaucoup moins mal vieilli que d'autres API (MFC & cie). Bon par contre elle ne s'est pas autant renouvelées que du Qt (qui est un produit excellent il est vrai, et basé sur une communauté très active, et avec un éditeur très proche de la communauté, il suffit de voir les échanges entre KDE et Qt pour s'en convaincre).

En fait je suis peut être mal habitué car j'ai beaucoup bossé sur devExpress, une librairie graphique commerciale très puissante en c# qui permettait de faire des UI étonnantes en juste quelque minutes et 100% design time.

J'ai vu un peu partout que netbeans avait un bon éditeur, mais je suis coincé sous eclipse avec mon projet puisque j'utilise un plugin très spécifique pour faire des simulations (repastS). J'ai quand même réussi à installer visual editor mais ça reste assez pauvre ce que j'ai actuellement à disposition.

Citation:

---

Je veux pas être sec ou quelque chose comme ça, mais généralement, avant de lancer des discussions à nature "trollesques", on se renseigne. Si j'utilise Swing, et que je trouve cette API vieillotte, je vais d'abord voir ce qui existe avant de lancer un troll pareil, ou au moins je demande des informations et parle en connaissance de cause. SwingX est même extrêmement répandu et de nombreuses questions liées à ce sujet sont présentes dans ces forums.

---

Super ça commence...
Déjà 1 tu noteras que dans mon post, à aucun moment je ne me suis exprimé de façon aggressive, conscient de ne pas être forcément au courant de tout j'ai utilisé des locutions telles que "il me semble que...." justement pour éviter de toucher un quelconque rageux dans son amour propre.

Et puis tu sauras que j'ai regardé un peu ailleurs, j'étais au courant pour swingx, j'ai aussi zieuter du coté des alternatives (SWT et co) mais je ne trouve pas du tout que c'est la réponse à tout, même si y'a certains éléments. Il reste que ces nouvelles API de validation sont tout de même encore à l'heure qu'il est de la musique d'avenir.

Donc maintenant il faut voir, c'est un forum? On peut discuter ou pas? Perso je suis ici justement pour entendre d'autres avis et trouver des solutions, "voilà ce que j'en pense", "voilà ce que j'utilise" par pour faire une guéguerre entre fanboys. Donc j'espère que si t'as eu un doute de ce coté là, c'est dissipé.

Sous eclipse il existe des alternatives à Visual Editor.

JFormDesigner est disponible sous forme de plugin eclipse,
Il y a également Swing Designer qui est un outil très puissant (mais un peu lourd) qui est capable de faire du reverse engineering sur des classes Swing.

Par contres ces éditeurs ne proposent pas (encore) de solution de binding.
Mais tu peux intégrer dedans n'importe quel composant Swing quel qu'il soit, pas uniquement ceux fournis en standard dans java.

Pour ma part je trouve JFormDesigner réellement bien fait pour le design d'interfaces, il produit un code clair, avec une séparation du layout dans un fichier XML externe et une librairie pour charger ces fichiers de description au runtime.

Ensuite pour la partie Binding/Validation, les librairies JGoodies sont fiables, matures et éprouvées, et permettent de correctement structure ses devs. Par contre c'est encore au niveau code que ça se joue.

Puis pour la couche de données suffit d'y aller par JPA avec les annotations, a moins d'un cas über complexe ça suffit amplement en ne demande pas des masses de dev (voir quasiment aucun car des outils permettent d'obtenir ce qu'il faut via reverse engineering sur la base).

Merci,
En d'autres occasions je n'aurai pas vraiment pris la peine de considérer un éditeur à priori "standalone" comme jFormDesigner mais sur tes recommandations, je vais l'évaluer.
Le système de séparation de la vue et du code à la manière QT n'est peut être pas une si mauvaise chose.

C'est bien que tu parles de ça parce que je suis tombé sur des articles JPA en cherchant un moyen de distribuer une transaction sur plusieurs méthodes en évitant au maximum les lourdeurs. C'est juste que je n'ai vu que des exemples j2ee pour l'instant, mais ça fera l'objet d'une autre demande de ma part.
Pour le petit besoin en base de donnée de ma simulation, j'ai utilisé simplement apache dbutils, mais je n'exclu pas d'avoir recours à du plus lourd dans les prochains projets.

Quand même cela fait plaisir de voir qu'il existe encore un champ d'exploration conséquent autour de tous ces problèmes.

JFormDesigner est également disponible sous forme de plugin Eclipse (et également pour IntelliJ d'ailleurs)