Discussion :

[Anysse]

Bonjour a tous,
je code un peu sous java, j'utilise normalement Netbeans et Matisse
Pour mon stage, je dois me familiariser avec Eclipse
En cherchant sur le net des plugins pour retrouver l'equivalent de Matisse et pour trouver un editeur graphique HTML, ou plutot JSP ressemblant a celui intégré dans MyEclipse
je suis tombé sur quelques post parlant de l'optimisation du code generé par ces editeurs graphiques. Certains pretendaient qu'il faut mieux tout coder a la main.
Le probleme qui se pose , n'est ce pas un peu "galere" de devoir calculer toutes les distances pour agancer tout les composants ?
Enfin est-il reellement possible d'arriver, sans y passer 15 jours.
Dispositionner tout mes composants, les Jpanel .... et produire une application au design plus que potable .
Voila merci d'avance pour votre sollicitation.
Bonne journée a tous

[jinh]

Salut,

C'est marrant, on a l'air confronté un peu à la même problématique: utiliser un éditeur ou coder tout à la main avec toutes les galères que cela entraîne.

Personnellement, je suis une école à dominante très prononcée Java. Mon prof(reconnu mondialement, je ne dis pas ça pour me la pèter) nous conseille vivement de coder à la main car les éditeurs font des trucs plus que crades question conception( héritage de JFrame etc...) qui sont utiles que dans certains cas(surchage de méthode paint par exemple).

Développant exclusivement sous Eclipse, je pense qu'il suffit de se faire la main plusieurs fois mais que le résultat en vaut la peine. Un code 100% maintenable sur lequel tu as entièrement la main.(D'ailleurs question Layout, GridBagLayout est plus que puissant).

Voilà mon petit avis,
Bonne apm

[Pill_S]

Personnellement, je trouve que le code généré par Visual Editor (sous Eclipse) est extrêmement propre, bien plus que ce que produit JBuilder...

C'est vite vu, chaque composant possède sa méthode d'initialisation, et qui de plus est paresseuse (lazy init)

Le code produit ressemble généralement à ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
class App extends JFrame {
  App(){
    super();
    initialize();
  }
 
  private void initialize(){
    setContentPane(getJContentPane());
  }
 
  private JPanel jContentPane = null;
  private JPanel getJContentPane() {
    if(jContentPane == null) {
      jContentPane = new JPanel();
      jContentPane.setLayout(new FlowLayout(FlowLayout.LEFT));
      jContentPane.add(getJButton());
    }
 
    return jContentPane;
  }
 
  private JButton jButton = null;
  private JButton getJButton() {
    if (jButton == null) {
      jButton = new JButton();
      jButton.setText("Click me!");
      jButton.addActionListener(new ActionListener(){
        public void actionPerformed(ActionEvent ae){
          System.out.println("Click button!");
        }
      });
    }
 
    return jButton;
  } 
 
  ...
}

Ce qui est pour moi la meilleure façon de coder une interface graphique

[natha]

Ce qui est pour moi la meilleure façon de coder une interface graphique

On devrait lancer un débat... personnellement je trouve que c'est une mauvaise pratique de faire des getters qui testent == null et si oui, construisent le composant.
La critique c'est que tu maîtrises mal l'ordre de création de tes composants ce qui peut conduire à des boucles infinies. C'est un code plus difficilement maintenable et difficile à appréhender.

Je préfère faire une méthode privée initComponents() que j'appelle dans le constructeur et qui va me créer tous mes composants à la suite. Je ne crée des getters que pour les panels et composants que j'ai besoin de récupérer dans des classes externes (et les getters sont classiques, pas de tests == null dedans).

D'accord / pas d'accord ?

[jinh]

Personnellement, je trouve que stocker une référence vers un composant graphique est inutile finalement, puisqu'on peut y accéder depuis son parent...

Et je rejoins natha dans l'idée qu'un getter reste un getter et qu'il n'est pas destiné à iniatialiser des composants...

[natha]

En fait je me rend compte que je n'ai pas répondu à la question initiale.
Pour ma part je code tout à la main et ça me prend un temps mesurable en minutes.
Nous utilisons JGoodies Forms pour la plupart des écrans :

http://www.jgoodies.com/freeware/formsdemo/index.html

Le FormLayout offre vraiment un code clair et maintenable contrairement au GridBagLayout qui est puissant, certe, mais qui est une usine à gaz à utiliser. Et le but clairement affiché par le créateur de cette librairie est de pouvoir réaliser de beaux écrans facilement.

En conjonction avec le BorderLayout et le FlowLayout, on peut tout faire facilement.

[Pill_S]

D'accord / pas d'accord ?

On va pas lancer un troll quand même

Concernant les boucles infinies, franchement je ne vois vraiment pas de quoi tu parles...

L'avantage de la manière que j'ai évoqué, c'est que chaque composant est initialisé dans sa méthode à lui, et pas ailleurs... Le code est mieux structuré, plus clair et plus facile à maintenir (si je demande à quelqu'un de modifier tel ou tel composant, il n'a qu'a chercher la méthode getXxxx et modifier ce qu'il faut). Et si un composant doit devenir accessible aux autres classes, il n'y a que le modificateur de visibilité à toucher, le reste ne change pas

Les méthodes sont aussi plus courtes, puisqu'elles ne traitent qu'un seul composant.

Quant à l'idée d'accèder un composant via son parent, je trouve ça laid (j'aurais pu dire quelque chose de bien plus "gras", mais je n'ai pas envie de choquer)


Mais je serais intéressé à voir un exemple pertinent où ma manière de faire pourrait poser des problèmes...

[natha]

Pour les boucles infinies j'avoue que ce n'est pas fréquent et ça n'arrivera jamais avec un développeur expérimenté. Mais nous avons des stagiaires et le code produit est souvent un copier/coller de copier/coller de copier/coller d'autre code (téléphone arabe) avec à chaque fois l'ajout de subtilités pas forcément très propre. Il arrive que dans le getter, le composant ne soit pas initialisé de suite.
Pendant cette initialisation appelle un autre getter qui rappelle le getter en cours. Le composant n'étant pas initialisé, les getter se rappellent en boucle.
Je n'ai malheureusement (heureusement ) pas d'exemple étant donné que ce genre de comportement est corrigé avant commit.

L'avantage de la manière que j'ai évoqué, c'est que chaque composant est initialisé dans sa méthode à lui, et pas ailleurs...

Dans mon cas chaque composant est initialisé dans la même et unique méthode (initComponents()). Un minimum de commentaire permet une lisibilité à toute épreuve. Et l'ordre d'initialisation est connu. Avec les getters on a du mal à savoir ce qui est initialisé avant quoi et ce qui n'est jamais initialisé (code mort). Il est également pratique d'avoir toutes les initialisations de composants de même type au même endroit plutôt que disséminé dans la classe (par exemple les actions et les boutons).

plus facile à maintenir

Là je dirais que c'est une question de point de vue. Je trouve plus difficile à maintenir le code avec getter pour les raisons invoquées ci-dessus. Je trouve également plus lourd de rajouter une méthode par composant.

Les méthodes sont aussi plus courtes, puisqu'elles ne traitent qu'un seul composant.

Tu as plein de petites méthodes, j'en ai une seule mais grosse... au final j'aurais moins de lignes de code en tout car je n'ai pas toutes les lignes == null, les déclarations et les return. De plus quand tu fais une méthode, la bonne pratique est de mettre une javadoc ce qui n'est pas vraiment utile et surtout redondant dans le cas d'initialisation de composants.

Quant à l'idée d'accèder un composant via son parent, je trouve ça laid

Alors là je suis complètement d'accord.

[Anordem]

Personnellement, je suis une école à dominante très prononcée Java. Mon prof(reconnu mondialement, je ne dis pas ça pour me la pèter) nous conseille vivement de coder à la main car les éditeurs font des trucs plus que crades question conception( héritage de JFrame etc...) qui sont utiles que dans certains cas(surchage de méthode paint par exemple).

Bonjour, j'ai commencé le Java il y a 3 semaines donc je ne connais pas encore toutes les subtilités du langage. Cependant je ne comprends pas pourquoi hériter de JFrame est crade et surtout, quelle est la bonne méthode dans ce cas ?

J'utilise Eclipse avec Visual Editor et je trouve le code généré très clair et propre. Mais bon, je n'ai pas encore eu à créer de grosses applications.

[Pill_S]

je ne comprends pas pourquoi hériter de JFrame est crade

Moi non plus je dois dire

On doit hériter de JFrame quand on veut une fenêtre principale de programme, de JDialog quand on veut un fenêtre de dialogue secondaire, et de JWindow quand on veut une fenêtre sans bordure. Là où ça devient crade, c'est quand on hérite de JFrame pour une fenêtre de dialogue secondaire ou de JDialog pour une fenêtre principale

[jinh]

Salut,

Je dois dire que c'est animosité et sans critique tranchée de vos méthodes que j'ai cité l'avis de mon prof. Cependant, la raison d'un point de vue design pour laquelle il ne faut pas hériter de JFrame est que l'héritage en langage Objet est destiné à complémenter, ou à surcharger des méthodes de la classe héritée.

Ce qui n'est résolument pas le cas dans le code généré par les éditeurs graphiques ( c'est plutôt par souci de lisibilité que c'est fait).

Donc la méthode à suivre consisterait à construire sa JFrame et à la complémenter par l'intermédiaire de méthodes (statiques ou non) qui renvoit un objet du type voulu(JPanel, JButton etc) et de les inclure dans le bon container.

[natha]

Je ne sais pas.
Personnellement j'aime bien étendre JFrame et JDialog car conceptuellement, ma fenêtre a des méthodes supplémentaires qui permettent une gestion de raccourcis clavier, de fermeture correcte des écrans et sous-composants etc... En fait j'ai une AbstractJFrame qui étends JFrame et qui est elle-même étendue par d'autres classes. On pourrait effectivement faire autrement sans faire plus de code ou perdre en simplicité mais ça n'a rien de choquant je trouve. Plutôt une question de choix.