Reprise du message précédent :

ouais, mais on est sensé hériter de trucs un peu hortogonaux, pas trop au sein de la même hiérarchie.
 
 
edit : heu en héritage plutiple je parle

je vois pas ce que tu veux dire par "truc orthogonal", mais si, c'est même fréquent que ce soit au sein de la même hierarchie ... C'est plutot logique d'hériter d'objets (ici d'interfaces) proches ...
Enfin, le problème se pose dès que tu veux implémenter 2 interfaces ou hériter d'un objet un implémenter une autre interface, etc ... C'est quand même relativement fréquent

tiens je suis en train de me rendre compte que je code tout mon Swing en static...en faisant des factories...j'ai vraiment pas de méthode en Swing, faudrait que je trouve de la bonne litérature accessible sur le sujet...
 
en gros g une classe mère qui contient la frame, et tt les éléments de la frame sont faits par des factories avec un méthode statique genre getToolbar()...
 
pareil je trouve que peut etre je divise trop en classes, je devrais peut etre faire plus de inner classes...
 

Jubi > il vaut mieux découper en trop de classes que pas assez, en progressant, tu sauras réduire. Mais au début, il vaut mieux rester très académique et très "pur" niveau objet.

disons que c mon prédécesseur sur le projet global (enfin concernant ce petit utilitaire c moi qui l'ai créé depuis le début) m'a foutu les jetons...classe monolithique de 3000 lignes avec 50 MyActionBidule à la fin, etc...là du coup je sépare à mort...d'ailleurs les exemple Java tutorial sont limites sur ce coup : pour swing, ils font un gros usage des inner classes, ce qui fout le bordel parce qu'on peut pas les instancier de l'extérieur...donc si c voué à etre utilisé par plusieurs classes, je trouve que l'inner c pas la panacée (surtout pour les actions dont par def c pour plusieurs objets.)
 
==> merci de m'avoir fait découvrir SVN et Subclipse...c bien pratique...g poutré au moins 10x mon repository pour cause de refactoring ou de move qui plante, mais ca m'apprend

hannn p'tain y'a suriiiiiii

jubijub >> bah ouais, personne sait pourquoi mais les exemples swing sont plus que trop souvent pourris

--> ca illustre un méchanisme, après ca s'adapte...mais pour mixer 2 tutos c relativement le bordel...par ex, pour faire une toolbar avec des icones...ca dépend de 2 tutos différents...et les 2 cohabitent pas bien

 
       
 
et j'ai meme un deuxieme pb
Commment on fait pour rafraichier un JPanel?
explication: j'ai un jpanel avec des elements pas visible par defaut, et selon certain truc je veux les rendre visible.. je fais donc: getMonPanel().getMonBouton().setVisible(true) mais ca marche po
j'ecume google mais surement pas au bon endroit..  
 
 

 
validate()
 
edit, elles sont pas sympetrique ces lunettes, tu va nous arranger ca  

 
ca marche pas
 
edit: c ce qui fait toute leur classe

g eu le même pb...g contourné ca avec une méthode qui prend le panel en paramètre, fait les modifs, et le renvoit, et le panel est remis dans son container...et là ca marche, mais c surement très sale

java cay l'futur qu'ils disaient

j'en ai dans ma cafetiere

 
ouais mais non, jpeux pas faire ca sans tout degueulasser..

porcin mais isolé, tu peux rappeller la méthode qui crée le panel avec les nouvelles infos à mettre...
 
mais normalement y'a des méthodes qui forcent le refresh, mais je m'y suis pas penché

bon ben je comprend rien
<pour faire simple>
jusqu'alors, je creais un objet sur clic d'un bouton, et ds le constructeur de l'objet, je faisais les setvisible. => marche pas
 
j'essaye alors directement ds la gestion de l'evenement clic de changer les propriétés avec setvisible, et la ca marche... comprend pas
 
edit: tout le probleme se situe ds le fait que j'ai une grosse hierarchie d'objets, et j'ai pas envie de faire un switch pour afficher les trucs necessaire selon chaque obj c'etait mieux ds les objets eux memes

tu veux une fessée ?

ha, te v'la enfin

oué bah pour lire ça, j'aurais mieux fait de rester là où j'étais.

ouais mais réponds-y; ptet que je finirai par retenir comment faut faire, moi aussi

je plussois moins moins : quelle est la technique propre pour forcer un update en Swing ?
 
Tu parles d'évènement en général...tu peux préciser ?

j'en sais rien, il faudrait regarder le code, sauf que je suis un peu fragile moralement là, et j'ai déjà des démangeaisons à l'idée de ce que je pourrais voir si je lui demande son code.
 
 
(oui j'aide pas, mais y'a des moments où il faut penser un peu à soi)

y'a pas une idée generale à retenir ?

il est hors de question de forcer quoi que ce soit dans ce cas là. Une aggrégation swing, c'est un arbre énorme, où tout le monde connait ses parents et ses enfants, un évènement arrivera bien à se propager tout seul. Si on dit à tout le monde faire des setBidule, c'est bien pour prévenir les observateurs il me semble.

prenons le pb différement :  
 
comment tu implémenterais ceci :  
 
T'a un JPanel bourré de composants qui affichent des données susceptibles de varier. Prenons l'exemple d'un formulaire, avec des label, et des JTextField...
 
les données viennent d'un objet, qui est dans une liste qu'on peut choisir, genre une JList, un JTree, un objet renvoyé par l'élément [i] une Collection, l'enregistrement X d'une BDD, etc...
 
Tu veux que si tu cliques sur un nouvel objet, les données du panel soient mise à jour au moment du clic, et de manière optimisée (ce qui exclus l'effacement du panel et sa recréation)
 
(les autres complétez si vous trouvez que je me suis trompé/été imprécis)

 
voyons si g suivi : tu fous un listener sur la liste, ou le truc qui contient tt les objets, et le ActionPerformed doit faire les set sur le Panel ?

CardLayout, mais ça répond pas à la question de suri qui a *déjà* fait des trucs visibles et invisibles (Et le layout, il layout ça comment d'abord ? ça doit être un beau bordel).

mais non, quand tu fais un add() tout se démerde tout seul. Franchement, je vois pas l'intérêt des faire chier l'uilisateur d'une lib avec ça.

 
oué  

-->ok pour le card layout, mais ca répond pas à ma question...dans le cas du formulaire, les données à afficher sont tjs les même...si par ex tes objets c des élèves, t'aura tjs le nom, le prénom, etc...donc le layout du panel change pas, c juste le contenu des JTextField...la question porte sur comment faire un refresh élégant des JTextField (ou autre genre checkbox, etc...

nan mais le layout il est là une fois pour toute il bouge pas. ce que suri veut je pense c'est par exemple quand il va cocher une checkbox donnée, ça fasse apparaitre tel ou tel textfield.
ce qu'il a fait pour le moment c'est appeler setVisible sur ces textfields lors des events sur la checkbox, mais ça marche pas

pour généraliser nos deux pb, c faire qu'à une action donnée corresponde un refresh du JPanel, sachant que son layout reste fixe (donc pas de cardLayout)

ah ok, bah écoute, MVC. tu auras un modèle Elève qui sera (dans le cas le plus "pur" ) une aggrégation de petit Documents. quand on clique sur le bouton, on change le modèle de l'élève, ça change tous les DocumentS des textField (Modèle comme aggrégation de petits modèles).
 

ouaip, je suis étonné. Je vais d'abord tester et ensuite investiguer si ça se confirme.

 
il est temps de te trouvé une autre images  

pour etre tout a fait exact:
soient le jtree, le bouton et la checkbox (enabled=false) suivantes (ds 3 panels differents):
http://suri53.free.fr/Clipboard01.jpg
http://suri53.free.fr/Clipboard02.jpg
qd je clique sur arbre ds le jtree, je catche l'evenement TreeSelectionEvent, je modifie le nom du bouton (la, ca marche) et je cree un objet Arbre qui, ds son constructeur ou ds une de ses methodes peu importe, va faire un setEnabled(true) de la checkbox (la propriété est bien modifiée...) mais ca n'active pas la checkbox...
 
donc: si je fais toutes mes modif de visibilité et tout ds l'evenement ca marche, mais si je le fais ds un autre objet ca marche plus
 
jpeux pas etre plus clair

c'est bien domage.

heu, je crois avoir compris : il veut qu'au clic dans son tree, la case devienne active...ce qui revient à mon exemple : modifier une propriété d'un objet lors d'une action sur un autre objet...