quel est votre style pour gérer les gui, évènement?
 
il y a des personnes qui prèfère la manière de jbuilder et cie pour gérer les gui et évènement (niveau code) d'autre non...
 
et vous? (avec exemple svp)

tout a la main

+1, par contre je déroge au MVC par flemme, en incluant l'ActionListener à la vue. ça donne des trucs comme :
 

moi je fais plutot des inners classes private pour ce genre de cas... (même si c'est rare que je fasse des GUI)

ça m'arrive aussi. L'implémentation de MVC dans Swing ne m'a jamais convaincu de toutes façons.

en meme temps, MVC c'est pas necessairement LA réponse à tout. en outre, l'existence meme d'UN pattern mvc est sujet à controverse, et il semble que chacun y aille de son interpretation de ce truc

C'est la réponse actuelle, jusqu'à ce qu'on trouve mieux. Autant le  MVC2 des webapps me convient assez, autant Swing, j'ai l'impression que vue et contrôleur sont livrés ensemble.

tout à fait.

en meme temps, c'est le meme qui nous sort

 
 
faudrait savoir

Par flemme je ne me casse plus le cul à déporter mon contrôleur parce que tel que c'est contruit, une partie du contrôleur, le contrôleur par défaut fourni par les vues Swing, reste justement dans les-dites vues. J'aime pas. Par flemme également, je ne mets plus le contrôleur de côté car le surcoût en code (passage de paramètres) rend la maintenance plus difficile, au contraire de que l'on voudrait, donc.
 
Arrêtez de me traquer.

ça tombe bien, c'est le but. Le contrôleur est adapté à la vue (because affichage du contrôleur).

 
bin oui
 
cherrytree, qu'est ce que tu nous fais là?

Un cake ? Quand je me serai remis aux GUI, j'essayerai d'expliciter mon désarrois du pattern MVC Swing.

ca m'étonne que Taiche ait toujours pas débarqué  

Les IHM, sapu

 
comment reconnaitre le linuxien, tome 1
 
(C koi MVC ? )

Laisse-moi le temps, bordel J'ai toujours pas le Net, chez ouam
Sinon ba comme veryfree, j'fais tout à la main et en SWT

Personnellement, j'ai un objet ne dérivant de rien qui gère un composant, par exemple :

 
Pour les listener, c'est toujours à coups de classes anonymes :

Pourquoi ta classe View n'étend pas JPanel ?

Parce que tout ce que j'en souhaite, c'est qu'elle me crée elle-même son composant en lui spécifiant éventuellement les modèles ou autres objets dont elle aurait besoin. Je me limite à en récupérer un pour l'afficher, sans savoir a priori ce qu'elle est exactement. Je ne vais pas plus loin. Donc je n'ai pas besoin d'étendre un JPanel.
Je ne sais pas si c'est correct au niveau design, alors toute remarque est la bienvenue.

Ben, je préfère faire un
 

 
et c toi qui chie sur MVC en swing? Vu l'utilisation que tu en fais, je suis pas trop étonné
 

 
Dans ton cas, rien n'empêche la classe C qui utilise ton objet View d'appeler quelques méthodes spécifiques à un JPanel qu'il a héritées. Du coup, si un jour tu décidais de changer de composant (mettre ton JPanel dans un JScrollPane ou utiliser un JSplitPane par exemple), la classe précitée devrait être revue.
Dans mon cas, je limite l'interfaçage entre C et l'objet View. S'il faut paramétrer le JPanel de View, c'est à View de le faire et non C. Ça limite les problèmes si C est développée par quelqu'un d'autre et que je décide de modifier complètement l'implémentation de View.

What's the matter with you?
 
Qu'est ce qui ne te plait pas ? Tu ferais comment ?

Vu comme ça. En même temps, tous les composants d'interface graphique Swing étendent de JComponent, en fait je suis pas sûr que ce soit une bonne idée de se couper de cette filiation. ça doit être utile.

 
bin tu mélanges tout avec l'héritage que tu veux faire
soit, laisse tomber

+1, sans le

 

J'ai pas vu de méthode Swing prenant un JComponent en paramètre, sinon il doit y en avoir très peu. Alors autant utiliser un Component, plus générique.

Je ne suis pas d'accord. Deux fois. D'abord que tu me laisses dans mon ignorance. Ensuite avec ton point de vue. Les éléments type JPanel, JScrollPane, JTextField... sont des vues, je ne vois en quoi en faisant héritant mon composant View de JPanel, je suis à côté de la plaque. Non, décidément je ne vois pas et je veux comprendre.

Au temps pour moi, l'idée reste la même.

En plus j'apprends à programmer à toutes les nouvelles recrues. Si j'enseigne des conneries, mes connaissances, mes croyances, doivent être corrigées au plus vite. S'il vous plait.

La vue n'est pas forcément un objet graphique. Elle peut se servir (agrégation/délégation)  d'élément graphiques, mais rien n'oblige à ce qu'elle en soit un (héritage).
 
et même d'un côté, avoir un objet View sur lequel tu peux appeler les méthodes de JPanel, c'est assez étrange. Ta vue de devrait être capable de faire (méthodes) que ce que tu as prévu qu'elle puisse faire.
 
Maintenant, c'est vrai qu'on afit souvent un héritage de JPanel parce que c'est pratique et que ca permet de mettre ette vue dans un autre context graphique, mais pourgarder une vision purement objet-théoricienne, c'est pas très logique.

Néanmoins, il n'y a pas de mal d'hériter d'un JPanel pour apprendre à l'utiliser et ne pas s'embêter avec ces histoires de connectivité et de cohésion (c'est comme ça qu'on les appelle, non ?). Il faut juste ne pas oublier de corriger le tir en vue d'un projet plus poussé.

 
ou bien si on veut faire du vrai MVC ...
 
> Cherrytree, je n'ai rien de particulier contre ton approche mais pour un gars qui critique le MVC utilisé dans SWING, je te trouve un peu gonflé vu comment tu l'utilises ...

Je débarque. ça doit être des concepts importants mais je n'en ai jamais entendu parler. Un lien ?

+1
 
moi je dis qu'il bluffe !

Ecoute, j'ai lu des centaines de pages sur Swing, j'ai fouillé Core Java 2 (tomes 1 & 2), Core JFC, Core Swing Advanced Programming, Beginning Java 2... sans compter les classes Swing que je me suis farci pour saisir le fonctionnement interne. J'ai analysé le code, j'ai synthétisé les pratiques des gens qui ont écrit les bouquins, les classes et ça donne... ma putain de manière. Alors tu comprends, le temps que j'ai investi, ce n'est pas rien. C'est considérable au contraire, et en fait ce n'est pas grand-chose, je ne sais, à vrai dire, pas créer un composant texte capable de gérer la coloration de quelques mots clés.
 
Et la je me retrouve devant trois personnes, trois puits de sciences qui savent un truc que je ne sais pas. Je bave, je piaffe... mais excuse moi encore d'insister : je veux vraiment savoir comment tu fais. A ce stade, je me fiche pas mal d'être gonflé.

 
Quand tu comprendras que c'est le personnage que je critique et pas la méthode, ca ira déjà mieux
 
La seule chose qui me dérange, c'est que tu critiques la façon dont SWING utilise MVC alors que dans le même temps tu l'utilises mal (benou t'as déjà expliqué pourquoi)
 
Personnellement je n'ai pas *la* solution sinon je me serai fait une joie de la transmettre (je n'ai d'ailleurs jamais dit que je l'avais d'ailleurs).
 
relis mes posts et tu verras où je voulais en venir.
 
Edit:
 

 
vu ta solution c'est pas étonnant
 
Re-Edit: je te chercher hein si t'avais pas compris

Je n'ai pas de lien. Je te ferais un petit copié-collé (ce serait plutôt un recopié ) de mes cours de génie logiciel ce soir.

(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 ...