Swing 100% à la main! Pourquoi?

J'ai parcouru (en diagonale) les forums, les faqs et les cours généreusement offerts sur ce site, à la recherche de la réponse à ma question!

Comme pas mal d'entre nous, j'étais et je le suis toujours, un développeur Delphi. Avec son excellent editeur de gui, et sa VisualComponentLibrary, on est tranquille, et rapide dans le développement.

Donc dans ce site, et dans tous les livres du commerce (presque), quand il s'agit de traiter d'interface graphique, le mot d'order est toujours : A vos clavier. On tape du code à ne pas en finir, même un projet avec 3 ou 4 Forms donne du fil à retordre!!

Jusqu'au jour ou j'ai installé Netbeans avec son merveilleux Matisse.

Seulement dans le maché de l'emploi, Netbeans est presque un inconnu, et quand une offre d'emploi exige la maitrise de swing, cela sous-entend savoir taper à la main ses interfaces et ses évènement.

Celà me parait assez primitif en cet année 2008!

Qu'en pensez-vous?

Pour moi un bon programmeur doit savoir coder à la main pour pouvoir utiliser un éditeur visuel. Ceci afin que lorsqu'un problème survient, il maitrise le code généré. 8-)

Utiliser un éditeur visuel, tout le monde peut le faire, ça ne prouve aucune compétence particulière. :?

Utiliser Matisse oui, mais il faut savoir faire pareil à la main.

Et sinon, en utilisant les bonnes librairies, comme le FormLayout de JGoodies ou TableLayout de JeSaisPasQui, construire un écran rapidement est aisé.

Merci natha pour ton intervention,

Il y'en de bien très bon programmeurs qui ne font jamais d'interfaces graphiques, ni manuellement, ni par un éditeur. Savoir taper du swing ne fait en rien la qualité d'un programmeur, à moins que ce soit sa spécialité.

Coder des interface est un procédés répététif et fastidieux, qui prend trop de temps et qui ne laisse pas le programmeur se concentrer sur la partie métier de son application.

Le seul avantage, d'après moi, à coder son interface à la main, c'est l'organisation et la "propreté du code". Chose bien géré par Matisse!

Si je reprends l'exemple de Delphi, son éditeur et sa VCL qui vont bienôt fêter leur 18 ans, je suis prêt à parier que 99% des développeurs n'ont jamais créé des interface à la main, à part bien sur les créateurs de composants et quelques autres cas bien particuliers qui requierent un exécutable de petite taille, ou un affichage accéléré (opengl, directx).

De toute façon, je pense que les editeurs visuels de GUI vont prendre une plus grande ampleurs les années qui suivent. Y'a pas mal de plugin sur eclipse déjà.

Quand j'ai commencé à programmer avec Swing en 2001, à l'époque il faut dire que les GUI Builders de qualité n'étaient pas légion. Il y avait alors un intérêt assez fort pour développer à la mano les IHM en Swing.

Par contre depuis l'arrivée de Matisse, l'intérêt de développer des IHMs à la mano reste réduit et surtout en ces temps de fort productivité. Par ailleurs, il y a certains Layout qui nécessitent l'utilisation du GUI Builder Matisse tant ils sont complexes à utiliser.

A mon avis, les GUI Builder seront un passage obligatoire si on veut qu'une technologie soit facilement accessible. Développer à la mano est bien sur un plus mais je pense qu'il est plus important de comprendre les mécanismes de base (événements, notion de layout manager, les différents composants, notion de modèle, ...) que de savoir obligatoirement coder une IHM uniquement à la mano.

Enfin et çe sera le dernier mot, je pense qu'on va tendre vers des IHM décrites en XML. Le code dans tel ou tel boîte à outils sera automatiquement généré par le GUI Builder. L'intérêt du développement à la mano sera alors réduit ...

Citation:

---

Envoyé par keulkeul

Enfin et çe sera le dernier mot, je pense qu'on va tendre vers des IHM décrites en XML. Le code dans tel ou tel boîte à outils sera automatiquement généré par le GUI Builder. L'intérêt du développement à la mano sera alors réduit ...

---

C'est déjà plus ou moins le cas (chez crosoft c'est déjà acquis avec XAML, Flex idem pour Adobe et ainsi de suite) par exemple Netbeans crée en fait des documents XML qui sont transposés en code java par la suite. De même il existe un certain nombre de projets (SwixML et autres) permettant de générer la couche Swing à partir de XML. Et dans un cas particulier, un GUIBuilder comme JFormDesigner (un des deux cadors du marché avec Matisse) génère du code XML, code XML qui est soit traduit en java directement, soit traduit au directement runtime au moyen d'une librairie que l'éditeur a publié en OpenSource.

++

Citation:

---

Envoyé par rthriller

Il y'en de bien très bon programmeurs qui ne font jamais d'interfaces graphiques, ni manuellement, ni par un éditeur. Savoir taper du swing ne fait en rien la qualité d'un programmeur, à moins que ce soit sa spécialité.

---

Je n'ai jamais dit qu'il fallait savoir coder du swing à la main pour être un bon programmeur. J'ai dit qu'un bon programmeur doit savoir coder à la main pour pouvoir utiliser un éditeur visuel. En simplifié, il faut savoir faire soit-même ce qu'un GUI builder fera. C'est pas tout à fait la même chose.

Je ne dis pas non plus qu'il DOIT le faire mais qu'il doit SAVOIR le faire.

Tout comme un bon ingénieur devrait savoir faire ce qu'il demande à un technicien (afin de mieux déterminer les contraintes, les prérequis et les délais de ce qu'il demande par exemple).

J'utilise Matisse pour toutes mes applications.

Si encore il y avait des choses qu'on ne pouvait faire qu'à la main et pas avec Matisse, mais ce n'est pas le cas je pense.

Bon après de la à dire qu'il est super, moi je trouve pas, avant je programmais sur .net, et l'interface me décalait pas toute mon interface à chaque fois que j'ajoutais un bouton -_-.

J'ai utilisé à l'époque JBuilder 5 qui a une interface interne de création de fenêtre. Le code généré n'est pas top top à mon goût. En l'utilisant, tu devrais d'ailleurs pas trop être dépaysé car c'est du même auteur!

Je suis de l'avis de natha. Le fait qu'il existe des outils permettant de faciliter la création d'interfaces graphiques, ne doit pas nous faire négliger la connaissance de la création à la main d'une interface graphique. Donc, pour moi, clairement, un bon développeur graphique doit savoir développer des interfaces de qualité à la mano. Après, il est clair qu'utiliser le GroupLayout à la main, c'est du masochisme...

Bonjour,

En tant que débutant dans le monde AWT/SWING et Java, je trouve cela pas mal.

Mais ayant l'habitude de mettre la main dans le code, j'aime bien comprendre ce que fait le programme.
(j'ai eu trop de mauvaises surprises avec certains programmes qui consommaient beaucoup de ressources pour rien).

Citation:

---

Envoyé par rthriller

...
Seulement dans le marché de l'emploi, Netbeans est presque un inconnu, et quand une offre d'emploi exige la maitrise de swing, cela sous-entend savoir taper à la main ses interfaces et ses évènement.

Celà me parait assez primitif en cet année 2008!

Qu'en pensez-vous?

---

Le marché de l'emploi pour les clients, ou j'ai travaillé (grand compte), serait en retard de plusieurs années.
Les clients se méfient des nouveautés, ou surtout des environnements qu'ils ne maitrisent pas.

J'ai eu le même problème en leurs parlant de Linux, c'est pour dire.
Mais cela change doucement.

A+

Je vois qu'il l'a pas mal de divergence dans vos commentaires! Et là, je voudrais m'adresser au pro-hand-made-gui, A quel moment peut-on dire que tel ou tel programmeur maitrise swing? Quels sont les caractéristique d'un bon programmeur swing? Doit-on connaitre tous les composants et classes composant swing au millimètre près?

Je m'explique; Je projette à changer d'emploi dans les 6 mois qui viennent, et j'essaye de migrer mes connaissance Delphi vers java (se et ee). J'y met pratiquement 4 heures par jour (j'ai même laissé tomber counter-strike!! ;) ), mais je sent bien que cela ne va pas être suffisant. Donc pour optimiser, je voudrais savoir s'il est impératif de s'attarder sur toutes les subtilités de swing, ou s'il y'a seulement une poignée de composants, classe et techniques qui faut maitriser à tout prix. Après tout, dans la pratique, je pourrais mettre du netbeans, faire mon interface, et copier-coller le code générer.

voili voilou!

Avant de parler de "bon" programmeur, il convient de bien préciser sa définition et surtout le contexte dans lequel on emploie "bon".
- Si "bon" signifie efficace, entendre par là qu'il respecte les délais très cours qui lui sont imposés tout en respectant scrupuleuseument le caheier des charges qui lui a été donné, alors l'utilisation d'éditeurs de GUI peut se revéler très efficace dans la majorité des cas.
- Si "bon" signifie à maitriser à mort les outils mis à disposition par le langage, un programme utilisant exclusivement les éditeurs de GUI ne peut pas rentrer dans cette catégorie.

PS pour l'anecdote, je connais certaines personnes se qulifiant comme très bons informaticiens et programmeurs qui ne développent qu'en VB et qui sont incapable de convertir à la main du décimal/hexa en binaire...:lol:

Citation:

---

Envoyé par rthriller

Je vois qu'il l'a pas mal de divergence dans vos commentaires! Et là, je voudrais m'adresser au pro-hand-made-gui, A quel moment peut-on dire que tel ou tel programmeur maitrise swing? Quels sont les caractéristique d'un bon programmeur swing? Doit-on connaitre tous les composants et classes composant swing au millimètre près?

Je m'explique; Je projette à changer d'emploi dans les 6 mois qui viennent, et j'essaye de migrer mes connaissance Delphi vers java (se et ee). J'y met pratiquement 4 heures par jour (j'ai même laissé tomber counter-strike!! ;) ), mais je sent bien que cela ne va pas être suffisant. Donc pour optimiser, je voudrais savoir s'il est impératif de s'attarder sur toutes les subtilités de swing, ou s'il y'a seulement une poignée de composants, classe et techniques qui faut maitriser à tout prix. Après tout, dans la pratique, je pourrais mettre du netbeans, faire mon interface, et copier-coller le code générer.

voili voilou!

---

Avis personnel : Je considère qu'une personne maître réellement swing (à la main hein ;) ) lorsque cette dernière maîtrise les composants utilisant le modèle MVC (JList, JTable, JTree, JTextPane etc.) c'est à dire les Renderer, les Modèles, etc.
Pour ce qui est de la connaissance de tous les composants swing, il plus utile de connaître leur existance plutôt que de connaître le fonctionnement et surtout l'utilisation de chaqun, la maîtrise de la javadoc (nécessaire également) permet d'assurer cette tache uniquement lorsque l'on en a besoin.

Citation:

---

Si encore il y avait des choses qu'on ne pouvait faire qu'à la main et pas avec Matisse, mais ce n'est pas le cas je pense.

---

Il y en a pas mal, si comme moi tu fais des interfaces qui bougent pas mal, Matisse(notement le GroupLayout) seul ne suffira pas. Tu peux certes t'en sortir avec matisse plus du code pour modifier l'interface mais pour bien assimiler certains aspects comme les layouts, c'est quand même pas mal d'avoir fait du code à la main.

La plupart de mes projet sont fait sous Matisse mais sans GroupLayout pour rester facilement modifiable a la main.

Citation:

---

Envoyé par iohack

Avis personnel : Je considère qu'une personne maître réellement swing (à la main hein ;) ) lorsque cette dernière maîtrise les composants utilisant le modèle MVC (JList, JTable, JTree, JTextPane etc.) c'est à dire les Renderer, les Modèles, etc.
Pour ce qui est de la connaissance de tous les composants swing, il plus utile de connaître leur existance plutôt que de connaître le fonctionnement et surtout l'utilisation de chaqun, la maîtrise de la javadoc (nécessaire également) permet d'assurer cette tache uniquement lorsque l'on en a besoin.

---

Entièrement d'accord. Les composants complexes MVC peuvent être déroutants. Pour les autres, il suffit de savoir qu'ils existent et constulter la Doc au besoin.
Je rajouterais qu'il faut bien assimiler la problématique de l'EDT.

Matisse n'est pas la solution a tout.. parfois certaines choses étranges se mettent en place avec le grouplayout et impossible de revenir en arrière ..

Dans la version 5.5.1 il y a encore des bugs qui font que du code ajouté en post/pre initialisation ne sera plus accessible après un redémarrage de l'IDE et bien sur ce code est situé dans une zone non éditable par NetBeans..

Je n'utilise Matisse contradictoirement que pour des petits trucs et bien souvent comme j'aime bien chipoter le pouillème de mm je recommence plusieurs fois, je ne suis même pas sur finalement que ce soit un gain de temps..

Pour des trucs complexes je n'essaye même pas avec Matisse, mano direct.. je pourrais utiliser Matisse avec gridbaglayout comme je fais a la mano mais c'est plus long d'éditer tout ça a la souris qu'en tapant le code alors... et l'avantage et que je ne me retrouve pas a utiliser un autre éditeur pour corriger un truc auquel je n'accède plus a cause d'un bug dans NetBeans..

Le truc qui est pénible c'est pour la plateforme, si tu veux faire a la main un TopComponent, pas d'autre choix que d'éditer le fichier a la main après sa création par le wizard pour virer les commentaires qui empêche l'édition.

Je n'ai rien contre les GUI designer mais ils ne doivent pas a mon sens restreindre les possibilités du développeur et ce n'est pas encore le cas de Matisse encore un peu trop buggé a mon gout.

Bulbo ;)

Merci, vos réponses me rassurent.

Je vais "décortiquer" ces composant MVC d'ici la fin du mois, et puis je continue mon apprentissage en migrant un projet concret que j'avais développé en Delphi.

Encore merci.

Citation:

---

Envoyé par iohack

Avant de parler de "bon" programmeur, il convient de bien préciser sa définition et surtout le contexte dans lequel on emploie "bon".

---

Alors je précise :) vu que ma définition de "bon" n'est ni l'une ni l'autre de celles que tu as proposé.

Pour moi un "bon programmeur" dans ce contexte sait :
- réaliser ce qu'on lui demande dans le temps planifié (par forcément le temps imparti, le temps "réaliste")
- maintenir ce qu'il a produit (et c'est là qu'il faut surtout maitriser Swing dans le sens MVC, EDT, Renderer, Editor)

Par ailleurs on est plus efficace avec un GUI Designer quand on comprend ce qu'il produit.
Et je répète, faut pas être développeur pour savoir utiliser Matisse donc je ne suis pas étonné que ça n'ai aucune valeur sur un CV.

;)

Citation:

---

Envoyé par rthriller

Je vais "décortiquer" ces composant MVC d'ici la fin du mois, et puis je continue mon apprentissage en migrant un projet concret que j'avais développé en Delphi.

---

Je te conseille le bouquin : "Les cahiers du programmeur Swing". C'est très bien fait pour comprendre et maîtriser les différents aspects de Swing.

Comme dit dans un autre post, coder un GridBagLayout à la main c'est du masochisme alors renseigne toi sur le FormLayout et/ou TableLayout.

Citation:

---

Envoyé par rthriller

Après tout, dans la pratique, je pourrais mettre du netbeans, faire mon interface, et copier-coller le code générer.

---

Nan c'est pas aussi simple, je pense que Matisse fait son petit code maison qui n'est compatible qu'avec lui-même ^^.

Sinon pour répondre, oui je pense que Matisse peut être utile dans la majorité des projets, et qu'il est plus productif dans ces cas là.
Dans tout ce qui est applications plus complexe (interface dynamique par exemple), c'est clair qu'il vaut mieux avoir le contrôle sur le code.

Citation:

---

Je te conseille le bouquin : "Les cahiers du programmeur Swing". C'est très bien fait pour comprendre et maîtriser les différents aspects de Swing.

---

Il y a aussi, "Swing la synthèse", que j'ai préféré à celui pré-cité, mais ce n'est que mon avis.

Citation:

---

Envoyé par natha

Je te conseille le bouquin : "Les cahiers du programmeur Swing". C'est très bien fait pour comprendre et maîtriser les différents aspects de Swing.

Comme dit dans un autre post, coder un GridBagLayout à la main c'est du masochisme alors renseigne toi sur le FormLayout et/ou TableLayout.

---

J'utilise a 98% du GridBagLayout pour des GUI complexes (et a la main!), j'ai une fois été confronté a un problème du fait que je n'avais pas la main sur le container principal (dans le NetBeans RCP) et le FormLayout m'a sorti de la panade.

Si tu écris proprement ton code, un GridBagLayout c'est très maintenable et plus simple au final que les empilements délirant de Panel que l'on voit parfois, chacun avec son propre layout (plus simple que le gridBag) mais qui réagissent pas toujours comme on s'y attend une fois que l'on commence a changer la dimension de la fenêtre..

Le seul inconvénient du GridBag est qu'il y a un apprentissage a faire, ceux qui connaissent ne jure plus que par ça, les autres suivant leur talents soient bidouilles avec des layouts simple ou d'autres genre Form et TableLayout, les plus doués (et maso) développent le leur :aie: ce qu'a fait un collègue a moi un truc a mi-chemin entre le Form et le Table avec plus de chose a connaitre au final que pour un gridBag et quant j'ai viré son truc pour mettre un GridBag certains bug au redimensionnement ont disparu et le code a perdu beaucoup de lignes et de panel inutiles.

Je reproche au FormLayout une terminologie complexe et finalement moins de flexibilite que le GridBag.

Ajouter un composant au milieu d'une fenêtre avec un Form (et surement aussi avec un Table mais je connais pas trop celui la) signifie revoir les contraintes de tous les composants ajoutés après celui la 8O
Niveau maintenance on a vu mieux.

Dans un GridBag il suffit de mettre les contraintes qui vont bien pour ce composant et zou .. dans les cas les plus complexes il faut rajouter 1 a la hauteur d'un composant sur un des cotés mais en général on n'affecte pas le reste des composants..

Bulbo ;)

sans compter que le layout de jgoodies a parfois quelques défauts quant à la gestion de JScrollPane... malgré tout ca reste un excellent layout....
je sors un peu du sujet là, non ?:D

Citation:

---

Envoyé par xixi31

sans compter que le layout de jgoodies a parfois quelques défauts quant à la gestion de JScrollPane... malgré tout ca reste un excellent layout....
je sors un peu du sujet là, non ?:D

---

Meuh non :lol:.. et JGoodies n'est pas le seul a avoir des problèmes avec les scrollpane, le GridBag a le même problème.. une sombre histoire de minimumsize et de preferredsize si je me rappelle bien..

Bulbo ;)

Citation:

---

Envoyé par bulbo

GridBagLayout

---

J'avoue avoir été un peu extrême à dire "masochisme". Je m'excuse et retire.
Dans notre cadre d'utilisation le FormLayout est massivement employé car nous faisons... des formulaires ;) Pour mettre des labels et des texfield, radio, checkbox, etc..., c'est top ! Pour créer une hiérarchie complexe de panels, c'est pas top, et des fois on utilise le FormLayout à tord.

Maintenant avec l'habitude on s'en sort très bien et on connait les pièges à éviter au niveau du redimensionnement donc ça roule.

Nous avons de plus beaucoup de débutants, alors les former chacun à faire un GridBagLayout complexe... très peu pour moi ;) Le FormLayout est bien plus accessible.

Personelement je trouve de GridBag infame et je suis un farouche partisan de l'empilement de panel avec différents Layouts, A plupart du temps, je m'en tire bien avec seulement des BorderLayout, BoxLayout et GroupLayout

Ca doit dépendre des gouts.

je ne voulais pas taper sur le FormLayout, il m'a rendu bien des services et il est relativement simple à utiliser ;).

Globalement tant qu'on en est a parlé de Layout, pour moi, les 2 indispensables sont le BoxLayout (qui semble gérer parfaitement les JScrollPane :lol:) et le GridBagLayout.

Citation:

---

Envoyé par Uther

Personelement je trouve de GridBag infame et je suis un farouche partisan de l'empilement de panel avec différents Layouts, A plupart du temps, je m'en tire bien avec seulement des BorderLayout, BoxLayout et GroupLayout

Ca doit dépendre des gouts.

---

Tant que tu obtiens ce que tu veux c'est parfait..

Maintenant tu peux ne pas aimer le GridBag mais niveau maintenance ton truc est un cauchemar..

Pour savoir comment va se redimensionner un composant tu dois refaire en sens inverse la hiérarchie de panel et appliquer dans le bon ordre les règles de chaque layout rencontré en chemin ..
En plus niveau perf, les events doivent se ballader a travers tout ce bazar, ce qui prend plus de temps (ok je chipote a mort la :lol:)

Bulbo ;)

Personnellement, je suis pas fan du GridBag. Trop complexe alors que tout ce que j'aime, c'est essentiellement faire de la programmation métier. Alors, bah, je sais ce que fait tel layout, ou tel layout. Il n'est pas rare que j'utilise 2 ou 3 layouts externes à ceux dispos dans AWT/Swing pour une même application (TableLayout étant le premier et ExplicitLayout le second) parce que ceux d'AWT/Swing ne me conviennent pas. Les uns pour leur trop grande simplicité et le gbl pour sa trop grande compléxité.

Mais la discussion semble trop s'orienter dans les layouts, alors que Swing n'est pas que ça (encore heureux).

Swing est un excellent outil pour réaliser des interfaces, mais pour le moment, je n'ai jamais eu l'occasion d'en développer une graphiquement. Mon expérience se limite donc à la création d'interfaces complexes à la main. L'avantage, c'est qu'il ne faut pas se restreindre à ce que propose l'outil d'interface. L'inconvénient est le temps mis à coder cette interface. Mais bon, cela me permet de bien approfondir ma connaissance de Swing. Du simple JButton aux complexes JTable et JTree (à quand le JTreeTable dans Swing, d'ailleurs ? ;) )

Pour les besoins d'une application, je me suis mis à l'HTML dans Swing, et là, il y a nettement du progrès à faire. À nouveau, j'ai du me tourner vers la communauté pour trouver quelque chose d'utilisable, et j'ai trouvé deux outils intéressants : l'un (dont je ne me souviens plus du nom) payant et l'autre gratuit/libre appelé FlyingSaucer. Ces deux outils m'ont permis d'utiliser la souplesse du HTML/CSS dans Java, ce qui a nettement boosté ma productivité. Si bien que maintenant, dès que j'ai une interface complexe à réaliser, je me demande s'il est possible de transposer ça aisément en HTML pour utiliser FlyingSaucer. L'ennui, c'est que je suis obligé de tout faire à la main, je n'aurai pas la possibilité d'utiliser un GUI builder, si jamais je m'y mets un jour.

Néanmoins, si je peux vous conseiller, en attendant l'arrivée de Java 7, utilisez AppFramework afin de vous faciliter le développement. Cet outil est une merveille qui sera intégrée dans Java 7 sous le package javax.swing.application (enfin, si tout va bien ;) ). Vous qui aimez travailler sur vos classes métier, il y a là un gain de temps extrêmement important !

Ayant appris à créer mes interfaces à la main au début, je confirme que ça peut aider pour comprendre ce qui se passe derrière.

Le GridBagLayout permet pratiquement de tout faire en contrepartie d'une certaine complexité même pour des IHMs simples, et c'est là que je préfère utiliser le GroupLayout (mais avec Matisse, pour ceux qui savent ce que y a derrière, un petit retour d'expérience serait le bienvenue).

Le FormLayout reste préférable aussi pour certaines IHMs, plus facile à créer qu'avec un GridBagLayout.

La connaissance des mécanismes qui sont derrière Swing (MVC, Listeners ...)est une nécessité si on veut aller loin avec !

Sur ce bon codage !

En conclusion, a après l'essai de pas mal d'outil pour le développement swing, partant de notepad++ jusqu'au trials des top des outils commerciaux, j'ai trouvé un bon compromis, entre édition visuelle et coding à la main. Il s'agit de JBuilder (la version turbo est gratuite) qui permet en temps réel de passer de la souris au clavier.

Donc il me créé ma JFrame et certains composants, et j'ajuste à la main tout en voyant en temps réel ce qui se passe visuellement! Et même le code qu'il génère est très propre.

Au fait ce n''est que le visual editor de eclipse :)

C'est bien jolie le wyzywig.

En 4 ans de Swing j'ai pas eu un seul projet ou je n'ai été contraint de produire des composants, ou d'affiner ceux de Java pour obtenir une haute rigueur.

Ensuite il faut souvent étendre les models (c'est le cas pour les tableaux), il faut définir les renderers. Mettre en place des patterns médiator à gogo, genre pour griser des boutons d'un menu selon le contexte etc... Il faut inventer des layouts managers (pour avoir des boutons sur une courbe par exemple) ou avoir une IHM scalable (zoom). Parfois on enregistre les actions utilisateurs pour faire des stats sur les chemins suivis et donc sur la cohérence de l'application (cf théorie des graphes).

Souvent l'IHM est polymorphe. C'est à dire qu'elle est générée de façon dynamique pour répondre à des contraintes. Je sais pas si un wyzywig aide pour cela.

Franchement la mise en page c'est rien à coté du don architectural qu'il faut avoir pour faire une GUI de haut niveau.

En peu de temps en lisant du code on voit l'IHM, comme un musicien entend la musique en lisant la partition (je deviens philosophe).

Maintenant si c'est pour faire un CRUD sur un base de données ok, ou une maquette ou un proof of concept, je pense que c'est bien.

PS: pour jsf aussi je trouve ca naif, car les IHM de demain ne sont pas de simples vues dont on passe de l'une à l'autre.

Citation:

---

Ensuite il faut souvent étendre les models (c'est le cas pour les tableaux), il faut définir les renderers. Mettre en place des patterns médiator à gogo, genre pour griser des boutons d'un menu selon le contexte etc...

---

faisable

Citation:

---

Il faut inventer des layouts managers (pour avoir des boutons sur une courbe par exemple) ou avoir une IHM scalable (zoom).

---

ca non.

Citation:

---

Franchement la mise en page c'est rien à coté du don architectural qu'il faut avoir pour faire une GUI de haut niveau.

---

un don? faut pas exagerer non plus :mrgreen:
on en est pas encore a sacrifier une chevre sur l'autel pour que le bidouillage marche. (on est loin de l'editeur visuel visual basic)


J'apprécie vraiment l'editeur matisse et tant que je peux je l'utilise. Il est quand meme tres flexible, on peut ajouter nos propres composants dans la palette. L'Internationalisation est aussi grandement simplifié (je ne dis pas que c'est dur de faire un ResouceBundle ...etc... mais ca fait ca de moins a penser) on est sur d'avoir toujours les clés présentes dans le bundle. Quand on a plus d'une trentaine de panneaux... je vous avous que ca m'enerve d'en avoir un qui refuse de s'afficher parceque j'ai mal ecrit une clé.


Quand il y a dans les interfaces des zones "dynamiques" c'est simple. Je colle un JPanel a cet endroit et je gere cette partie de l'interface en code.


C'est une aide, ca ne fait pas tout mais c'est un plus considérable.

Même les composants produits s'intègre facilement dans un éditeur wyzywig, et même les composants produits restent disponibles au programmeur pour subir tout type de manip (griser, cacher, ...)

Je ne parle pas d'une voix de grands expert, je n'ai pas tes 4 ans de swing. Je comprend bien qu'il est parfois plus facile de générer une interface avec du code, tu mets 2 boucles imbriqués et t'as ta calculatrice "prête à l'emploi".
Mais en général, faire des boutons qui suivent une courbe, ou qui se balladent dans un labyrinthe et tirent su tout ce qui bougent ça devient du counter strike (je rigole :) ), et ce n'est pas vraiment monnaie courante dans le développement des applications classiques (gestion, comptabilité, commerce, ...)

Je suis à 80% d'accord avec toi, surtout pour ce qui est du polymorphisme de l'interface, qui doit tenir compte des droits et autorisation de chaque utilisateur à accéder à tel ou tel module de l'application, ce qui implique la disparition des menus et boutons correspondant, ...

Le grand intéret des wyzywig (comme tu les appelle) c'est de mettre en place la disposition initiale et par défaut de l'interface (ça remplace le papier et le crayon), puis bien sur on a le choix selon le projet, de continuer visuellement ou repasser en mode texte.

Te faches pas de mes remarques, si je parles de couter strike c'est que ça me manque :)

Pour info ce n'est pas "wyzywig" mais "wysiwyg" pour "What You See Is What You Get" :)

Je crois quand même que vous oubliez l'essentiel ! (si on dérive un peu du sujet et que l'on se concentre plus sur un bon développeur d'interface que de la simple mise en page swing)

Pour moi, une interface applicative, en plus de la mise en page, c'est avant tout une véritable expérience utilisateur, une bonne gestion des évenements(de la validation, de l'animation, ...), un binding avec la couche de données souple et performant et une bonne gestion du multi-threading.

Hors c'est souvent là que les interfaces ont des lacunes, la cause à trop de temps passé sur la mise en page, alors que les editeurs visuels s'en chargent tres bien et nous font gagner énormément de temps ;)

Je pense que le vrai défi de ces prochaines années, c'est alors de disposer d'editeurs et de bibliothèques performants pour que les développeurs finissent de perdre du temps sur les problématiques techniques et qu'ils se concentrent d'avantage sur les véritables problèmatiques des utilisateurs, en leur proposant des interfaces toujours plus agréables à utiliser.
En adéquation directe avec ce qui se passe depuis quelques années sur la partie backoffice avec les spring, hibernate, jee, ... pour ne citer que ceux là.

Bon un peu hors sujet, mais je pense que ca méritait d'être souligné.

Hello.
Je suis entièrement d'accord sur le fait que lorsqu'on travaille le modèle d'une table ou ses renderers/editors (idem pour un arbre), il est vraiment indispensable de coder à la main. Mais jusqu'à preuve du contraire, ces compsants ne constituent quand même pas l'essentiel d'une IHM! On trouve souvent des tonnes de textFields, combo, checkbox, boutons, ... et pour tous ces composants basiques, le code "à la main" n'a aucun intérêt! Même remarque pour tous les conteneurs intermédiaires type splitPane, tabbedPane, ...

Vive les builders :yaisse2:

PS : ceci dit, je continue de penser que le builder idéal est loin d'exister en java. Matisse apporte pas mal, mais c'est pas encore le rêve... Et j'attend vraiment avec impatience l'environnement complet, avec GUI builder + RCP, tout intégré et facile à manipuler. Se tapper Matisse et le RCP Netbeans, ça demande quand même d'avoir fait pas mal d'études . Et la productivité n'est pas au top...:(
Si certains d'entre vous ont trouvé le bonheur, merci de partager!