Discussion :

[#define]

Bonjour à tous.

Les livres sur Java dont je dispose datent de 2008.
Tous (ex Programmer en Java - C. Delannoy) utilisent l'ajout par code des composants de style boutons, etc. sur une JFrame et traitent des actions avec actionPerformed et des sélections de style "if (e.getSource()== etc.)".

En considérant qu'un IDE est fait pour se simplifier l'existence, il me semble que le positionnement des composants tout comme la création des événements, par exemple de type "clic" sur un bouton (par exemple clic bouton droit sur le composant et sélection de Events > Actions > etc.) est beaucoup plus simple avec les fonctions fournies par l'IDE.

Dans le domaine professionnel, utilise-t-on l'ajout manuel de code ou celle proposée par les EDI ?

Merci pour vos réponses.

[apicard3]

On peut utiliser les deux. Une interface en java reste simple et sobre, il est tout a fait possible de l'utiliser pour un logiciel commercial tant que tu es le dernier maillons.

[cervo]

Salut, je te conseillerai la première methode ...t'as un contrôle sur ce que tu fais et tu le comprends mieux ! faut dire que je suis encore un developpeur traditionnel ! à un certain moment les IDE vont programmer à notre place ....(dsl HS )

[MasterMbg]

Bonjour,
Moi perso, quand je donne des formations en JAVA, je commence toujours par l'écriture du code à la main, sans IDE pour simple raison de permettre aux apprenants de maitriser ce qu'ils font pour que, quand ils vont entamer le développemment à l'aide d'un IDE, qu'ils soient à mesure de comprendre ce qui sera généré par ce dernier.
Conseil, Continue sans IDE, progresse, quand tu seras mûr tu veras que la vie sera plus facile avec l'IDE et tu seras plus souple et rapide en même temps.
PS : L'IDE ne donne pas TOUT!

[joel.drigo]

Salut,

En fait, la réponse est (à mon avis) : çà dépend. En fait, dans le domaine professionnel, on peut faire différents types d'applications. Un prototype, jetable, devra être fait le plus rapidement possible, et un outil de création d'UI peut permettre de mettre en place l'apparence globale fonctionnelle suffisante pour qu'on comprenne le fonctionnement de l'application par rapport à l'UI.

Dans le domaine pratique, lorsqu'on fait des applications industrielles, en tout cas, c'est le cas avec celle que je développe, on écrit une API qui génère automatiquement des UI, en fonction d'autres choses. Par exemple, mon application se connecte à un CMS, qui me fournit une API capable de fournir une description non seulement des propriétés qui décrivent mes objets, mes également d'informations qui concernent l'apparence des affichages de ces propriétés, ou de leur saisie (telle propriété affichable en liste, ou en formulaire, telle propriété éditable, ou pas, etc...), des informations également comme les valeurs par défaut, les tailles maximum d'upload pour des fichiers joints, etc... tout un tas d'informations qui peuvent être utilisées dans la constitution des formulaires, ou même liste (table), ou arbre d'objets : j'ai donc un code qui génère automatiquement des formulaires en fonction de ces paramétrages, et qui est interfacé par ailleurs par un système qui permet de personnaliser ces formulaires (ça peut se faire par des fichiers xml par exemple, ou des propriétés d'objets spécifiques du cms, ou autre). Dans ce cadre, un assistant est inutilisable. Et l'écriture du générateur nécessite de taper le code pour faire fonctionner les composants graphiques.

On pourrait citer d'autres cas de génération automatique : par exemple, j'ai au sein de mon application un générateur de dialogues, qui s'occupe de générer automatiquement tout type de dialogue, à choix multiples par boutons push ou radio, intégrant parfois une table, ou un arbre, et qui présentent, ou pas, une case à cocher liée aux préférences (du type : "retenir ce choix et ne plus poser la question"), etc...