Bon, la programmation Swing, tant qu'on veut pas faire du multi-threadé, c'est jamais qu'une grosse énumération d'objets Swing avec leurs propriétés, quand celles par défaut ne conviennent pas. Cela dit qqch me gêne un peu.
 
Alors que l'ensemble du langage dispose de conventions (nom de classes, accolades pour les blocs, saut de ligne, javadoc...), il n'existe rien concernant la manière standard de composer une GUI.
 
Disons que je veuille faire une GUI, je fais déclarer des données privées, un constructeur, des méthodes. Jusque là OK. Souvent les constructeurs de GUI sont gros, car il y a de multiples objets et des propriétés (editable, activé...), plus les listeners.
 
Cette approche désorganisée tranche complètement avec le reste du langage propre et convenue. J'aimerais savoir ce que vous en pensez et quelles sont vos conventions maison pour faire non seulement de belles GUI, mais aussi et surtout un beau codage de ces GUI.

Moi, pour clarifier un peu, je fais une classe pricipale qui herite de JFrame, et je fais l'initialisation (declaratoin des objets...) de chaque partie de l'interface dans une methode privee separee. Pareil pour les Listener, j'essaye d'en declarer un max comme classes privees, ce qui evite les blocs imbriques dans la declaration des objets.

C?est fou comment quand on comprend rien à java on a l?impression que tu es trop fort Cherrytree.
 
Pense:
(Merde mais pourquoi j?ai ouvert ma gueule moi ?
A oui c?est pour qu?il m?aide pour mon projet ! )
 
Et en fait je crois que c?est pas qu?une impression !!!!
 
Lèche lèche lèche !!! slurp

Babekiller a écrit a écrit : C?est fou comment quand on comprend rien à java on a l?impression que tu es trop fort Cherrytree.   Pense: (Merde mais pourquoi j?ai ouvert ma gueule moi ? A oui c?est pour qu?il m?aide pour mon projet ! )   Et en fait je crois que c?est pas qu?une impression !!!!   Lèche lèche lèche !!! slurp

 
Vas-y continue... Oui... OK, tu m'as convaincu.

 
Je pense en effet que c'est la seule manière actuellement. Mais elle fait un peu bricolage esthétique, et c'est cette liberté dans le domaine binaire (ô combien standardisé) qui me gêne, un peu comme quand la prof de dessin me demandait de rendre mon travail alors que j'étais en plein flou artistique.
 
Et à Namur ( ), c'est quoi les conventions Java Swing ? Si ça intéresse qqn, à Marseille, y a pas de conventions. A part des conventions footballistiques dans les centres culturels de la ville (les bars avec le logo l'OM ).

[jfdsdjhfuetppo]--Message édité par Cherrytree--[/jfdsdjhfuetppo]

Cherrytree a écrit a écrit :   Et à Namur ( ), c'est quoi les conventions Java Swing ?

 
Euh, je me sens visé tout à coup
 
Bin pour être franc: aucune. Je suis une vrai burne de chez burne en programmation GUI. Je n'ai jamais compris le système des layout manager et je compte m'acheter un bouquin asap car je suis vraiment trop nul.
 
J'ai un copain qui a écrit une librarie permettant de traduire une GUI VB en Java mais je ne sais pas ou ca en est.

C'est marrant ton post car j'y pensais justement à cette API VB -> Java parce que j'arrivais pas à dormir (cfr heure de post)
 

 
 

Alors, on est d'accord. Faire une belle GUI qui pète question code, c'est plus que chaud. Et ça m'ennuie beaucoup.
 
Néanmoins, si qqn a la méthode miracle pour faire un code de GUI qui soit beau à regarder...

Généralement, pour pas me faire chier, je fais une classe par "composant graphique" : je m'explique : dans mon applet de chat, y'a plusieurs zones : une zone de réception (en fait, elle est double, gérée par un onglet), une zone d'affichage de liste de contacts, une zone de choix du format du message, et une zone de boutons...
 
J'ai donc 7 classes : la super-classe des zones de réception, plus les deux classes des zones (elles ont des comportements différents), une class pour la liste, etc, etc...
Chacune de ces classes est une sous-classe de Panel (oui, c'est de l'AWT :,()  
Dans ces sous classes, j'ai généralement un constructeur public qui va instancier les attributs de la classe, pis j'a

Damend de touche tab!!
 
Donc, ensuite, j'ai une méthode fill, qui instancie les éléments graphiques "en plus" (labels, panels, etc....sur lesquels j'ai pas besoin d'avoir de référence) et qui fait le layout............
 
Généralement, je m'en tire avec moins d'une demi-douzaine d'éléments de base par classe...sinon, de toute façon, je redécoupe....ça veut dire que je me suis mal démerdé pour définir les responsabilités de chaque bout....
 
Et sinon, pour les interactions entre "gros bouts", généralement, je réécris mon propore manager d'évènements : en effet, le plus souvent, ces interactions correspondent plus à des évènements inhérents à l'appli qu'à des évènements purement graphiques (par exemple, quend l'utilisateur appuie sur le bouton 'envoi', je préfère notifier les autres éléments d'un évènemente 'envoi' que d'un évènement 'appui sur un bouton, qui s'appelle envoi' de cette façon, si le client change d'avis sur le design, mes communications entre éléments sont pas à refaire.  
 
 
De cette façon, par exemple, pour ajouter un label dans une zone, ou pour modifier l'aspectgénéral de mon machin, j'ai pas une méthode de 300 lignes à relire, et un layout de fou à travailler....D'un autre côté, j'ai beaucoup de panels, mais j'y gagne en lisibilité et surtout en réutilisabilité..
 
Ouala..
 
Sinon, pour le modèle du gestionnaire d'évènements, c'est très simple, il suffit d'avoir une interface MyEvent, qui définit une méthode 'handleEvent", et tu redéfinis cette méthode dans chaque classe d'évènement de la  façon suivants :
 
class TotoEvent implements MyEvent {
 
public void handleEvent(MyListener listener) {
  if (listener instanceof TotoListener) {  
         ((TotoListener)listener).handleTotoEvent(this);
  }
}
 
 
Pour la classe qui maage les évènements, le code est tout con :  
 
 
private boolean listensAlready(Object o) {
 for (int i = 0; i < listeners.size(); i++) {
     if (listeners.elementAt(i) == o) {
  return true;
     }
 }  
 return false;
    }
 
    /** Adds the given object as a MyEvent listener */
    public void addListener(Object o) {
 if (!listensAlready(o)) {
     listeners.addElement(o);
 }
    }
 
    /** remove the given object from the MyEvent listeners list*/
    public void removeListener(Object o) {
 listeners.removeElement(o);
    }
 
 
/** Fire the given event to the appropriate listeners.*/
    public void fireEvent(MyEvent event) {
 for (int i = 0; i < listeners.size(); i++) {
     event.handleEvent(listeners.elementAt(i));
 }
    }
 
 
où listeners est un vecteur
 
Avec un système comme ça, si une classe est listener de 3 types d'évènements différents, j'ai pas à me faire chier à l'enregistrer 3 fois auprès du manager...
 
Ouala!!!

Ah ! Voilà du consistant. J'ai le prof de JDBC qu'est revenu, alors je file, mais ça a l'air bien chouette tout ça... @+ et merci de t'être cassé le cul

ou chercher sinon le site de sun!
c ici exactement que j ai tout appris
http://java.sun.com/docs/books/tut [...] nents.html
 

Ouais, mais là y t'apprenne à utiliser les composants, mais pas à faire un code nickel, chaque exemple est codé à la manière du programmeur. C'est pas des conventions ça.

Le coup du vecteur de listeners, c'est une bonne idee.
Sinon, je viens de decouvrir Simplicity for Java (desole j'ai plus l'url). J'ai pas encore trop fouille, mais ca a l'air assez simple et plutot performant à l'utilisation.

c est le code des programmeurs qui on inventé ce language c pas rien

Si ça peux te renseigner, avant de poster, je me suis tapé les sources de la JComboBox et de l'algo DSA (codé par un français pour Sun, vu le nom de l'auteur) et ben le gars qui a codé la JComboBox n'est clairement pas aussi pointilleux que l'autre.
 
J'ai aussi regardé la classe String pour voir un peu, puis d'autres. C'est toujours bien codé, mais les préceptes du style saut de ligne, nombres d'espaces... ne sont pas toujours suivi. Moi je cherche la programmation ultime, le code pour une GUI qui fasse se pâmer Bill Joy et Scott McNealy.