Discussion :

[_skip]

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.

[dingoth]

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.

[_skip]

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.

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.

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.

[sinok]

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.

[_skip]

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

[dingoth]

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.

[sinok]

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).