Java, générateur d'interface graphique ou codage à la main ?

Question

Le logiciel de ma société comporte de nombreux formulaires, jusqu'à présent nous avons écrit le code manuellement (dans le style MVC).

Nous envisageons de commencer à utiliser un générateur d'interfaces graphiques.

Il y a quelques problèmes avec l'utilisation d'un générateur.

1. Des parties du code ne sont pas lisibles.
2. Des parties du code ne sont pas éditables.
3. Il sera plus difficile d'éditer le code plus tard.
4. Nous devrons continuer à utiliser le générateur à l'avenir, même si nous voulons le remplacer ou écrire manuellement, et personne ne peut garantir que l'outil sera disponible et pris en charge à l'avenir.

Je souhaite tirer des enseignements de l'expérience des autres :

• Recommandez-vous l'utilisation d'un outil ou devrions-nous continuer à écrire le code manuellement ?
• Quel générateur est le meilleur ?
• Comment faites-vous face aux problèmes ? (Y a-t-il d'autres problèmes ?)

Answer 1

Si vous n'avez pas des formulaires trop complexes à construire, alors vous pourriez jeter un coup d'œil à DesignGridLayout, c'est un LayoutManager Swing avec une API fluide qui rend très facile d'écrire du code pour votre formulaire et facile de lire ce code (et de le maintenir, je veux dire de le modifier si nécessaire) et de visualiser le formulaire à travers le code.

Avec DesignGridLayout, une ligne de code représente une rangée de composants dans votre formulaire. Pas de XML, une sécurité totale à la compilation. Pas de valeurs de décalage codées en dur, d'alignement... DesignGridLayout gère tout cela pour vous.

La courbe d'apprentissage est courte et rapide pour mettre en page un formulaire comme un concepteur GUI !

Depuis que je l'ai découvert il y a environ 2 ans, je l'ai utilisé exclusivement (j'ai toujours été allergique aux concepteurs GUI à cause du code généré terrible). C'est la raison pour laquelle j'ai repris le projet il y a 8 mois, car je voulais lui donner tout son potentiel.

Answer 2

Nous le faisons à la main, mais avec une bibliothèque qui nous aide avec la mise en page (JGoodies Forms) et ainsi de suite. De plus, nous utilisons un ensemble de composants prédéfinis que nous intégrons dans notre interface utilisateur (Jide). Cela fonctionne bien pour nous.

Answer 3

J'ai utilisé de nombreux concepteurs d'interfaces graphiques au fil des ans (pour différentes langues) : Delphi, Visual Studio, JBuilder, Netbeans.

La qualité du code qu'ils produisent et le volume sont importants. Delphi était fantastique, il produisait de petites quantités de code par rapport à la taille du formulaire et le code était facilement compréhensible. Les outils bidirectionnels permettaient de modifier le code généré en toute confiance. Cela a été facilité par une bibliothèque GUI simplement comprise. VS produit des tonnes de code et vous avez peur de le modifier.

Java est en partie laissé pour compte par le langage, pas de délégués ou de fermetures, de sorte que le code basé sur des événements peut rapidement devenir très étendu.

Je créerais des choses simples avec Netbeans Matisse et - une fois confiant - je les coderais à la main. Il vaut la peine de planifier et de coder à la main les choses complexes afin de bien définir votre modèle.

Il est utile de construire une bibliothèque de vos propres composants GUI que vous pouvez réutiliser. Cela est pertinent pour toutes les langues avec des bibliothèques GUI.

Answer 4

Pour les systèmes avec beaucoup de formulaires simples, j'ai tendance à prendre la route XML -

• définir des fichiers XML pour les informations et tout flux de travail pour chaque formulaire
• créer XSLT pour générer du code Java/XHTML/quelque chose d'autre pour exécuter les formulaires sur PC de bureau/mobile/web
• créer également XSLT pour générer des objets de données du code source, etc.

Vous pouvez utiliser XForms et ses implémentations, mais généralement j'ai travaillé dans des endroits où acheter des solutions prend plus de temps que de construire votre propre XSLT simple. Il faut généralement une semaine pour que tout fonctionne si les formulaires n'ont pas trop de widgets spécialisés. Si vous créez vos propres générateurs de code, vous avez un contrôle total. Si vous décidez de basculer tous vos formulaires de défilement haut/bas à une présentation en colonnes, alors il suffit de modifier un seul endroit, plutôt que de modifier l'implémentation de chaque formulaire. (bien que vous puissiez créer un framework pour abstraire les informations de formulaire de la présentation en Java, ce n'est pas vraiment adapté à une telle programmation déclarative)

Answer 5

Personnellement, je suis un partisan de la séparation de la mise en page de l'interface utilisateur du code (autrement, vous vous retrouvez avec les problèmes que vous venez de mentionner). Cela semble également être la tendance : Microsoft a leur XAML, on entend parler de différents moteurs de vue pour MVC, etc.

Pourquoi ne pas opter pour la conception d'interface utilisateur basée sur XML? Vous pourriez essayer quelque chose comme JFormDesigner qui peut gérer à la fois les mises en page en XML et générées par du code.