Reprise du message précédent :
(en réponse à cherry)
 
mais nan !!!!!
 
comme je te le disais c'est purement thérorique à la con ! Quand tu penses à l'Objet Vue d'une application, ce n'est pas "logique" de le concevoir en le faisant hériter de JPanel, c'est tout.
 
Maintenant si pour des raisons de réutilisabilité, d'implémentation, de cohérence avec le reste de l'appli, tu trouves qu'il faut le faire hériter de JPanel, et ben juste fais le. C'était une remarque conceptuelle.
 
Enfin ca, c'est juste mon avis en arrivant très tard dans le post. C'est peut être pas ce que voulais dire Dark ...
 
Je ne me permetrais jamais de mettre en doute tes connaissances sur Swing alors que c'est un domaine que je connais vraiment très mal ...

 
C'est *exactement* ce que je voulais dire. Je n'aurai meme pas tilté sur la solution si il n'y avait pas eu cet avis douteux sur MVC/Swing
 
bref, on se trompe de débat ici visiblement. Je pensais pourtant que c'était clair

je suis pas loin d'être de l'avis de Cherry ...
 
Je connais pas trop donc je ne me permet pas de juger, mais j'ai l'impression qu'en interne, Swing utilise très firtement le modèle MVC, mais qu'en utilisant Swing, c'est très dur de respecter ce modèle...

Plus que ça, celon le preincipe de substitution de Liskov, si tu hérites de Jpanel, tu _es_ un JPanel, dans le cas où tu fais hériter un composant de JPanel, tu fais quoi des add(), des pack() et de tout le bordel dédiés à gérer le contenu de ton panel ? Tu ne peux pas les réécrire en mettant du code vide dedans à cause (entre autres) de l'invariant qui dit que si un utilisateur fait un add(sonComponent), il est _sûr_ de le retrouver en cherchant dans le contenu du panel.
 
d'autre part, le code et les données héritées d'un JPanel sont becoup trop importants pour faire une simple vue.
 
JPanel, on l'étend si on veut faire un joli panel avec des fleurs sur les côtés, mais avec un joli trou dedans pour afficher ce que l'uitilisateur de la classe veut mettre comme composants dedans. Pas pour faire un truc dont le contenu est fixe et qui n'a pas de  place prévue pour que les utilisateurs mettent leur composants à eux.

bha oui ... c'est ce que je disais dans le post précédent ...
 
En fait, pour pouvoir être affiché, c'est plutot d'un java.awt.Component (y a pas d'équivalent Swing je crois) que ca devrait hériter. (quelle horreur cette classe, soit dit en passant)

Benou > là j'ai mieux compris mon erreur
 
. En somme en voulant trop faire vue (regardez, regardez, je suis un JPanel - ou JComponent - je suis forcément une vue), j'ai oublié le contrat terrible que je signais.
 
Merci infiniment.
 
nraynaud > tu as décidément un savoir étonnant. Peux-tu me donner encore un ou deux autres conseils sur le sujet ?

Dark > Swing est un sujet sensible. J'ai consacré énormément de temps. C'est toujours catastrophant de se rendre compte que partant seul, on s'est trompé, au sens propre. C'est moi qui ai trompé le programmeur.
 
C'est aussi un rêve gâché. Je n'ai pas réussi avec Swing à faire ce que je voulais. Je n'ai pas réussi à maîtriser Swing.
 
Je continue à penser que Swing n'est pas conforme MVC. D'ailleurs, dans Swing Connection, les ingénieurs présentent le pattern en introduisant ce qu'ils appellent le "delegate", lequel m'est toujours apparu comme un agrégat de vue et de contrôleur.

 
je trouvais ca bien moi

Pleure pas, faire comprendre ce n'est pas forcément un acte unilatéral. Si je n'ouvre pas mes esgourdes, tu ne peux rien m'apprendre.

nan mais c'est pas grave hein

Sur swing, non, je l'utilise très peu (et uniquement sous la contrainte), sur l'objet en général, il faut lire Bertrand Meyer et Robert C. Martin (fait la recherche, j'en ai marre de google, je passe ma vie dessus).

merci.

Comme prévu, quelques extraits :

 
Ton problème s'apparente ainsi à une faible cohésion, comme nraynaud t'a si bien expliqué.

merci.