Dans un programme de compta que j'écris actuellement j'utilise très souvent ce qui devrait à mon sens être un composant : une JList incluse dans un JScrollPane, avec un DefaultListModel comme modèle, et des méthodes, d'ajout d'objets, de mise à jour de ces objets et de suppression. C'est hyper classique comme utilisation d'une JList, et c'est pour cela que je voulais en faire une classe. Seulement, je me heurte à des problèmes de design. En fait je doute que cela soit une bonne idée, car cela me force (me semble t'il) à intégrer tout MVC dans la même classe. Des idées ?

Perso je mettrais en place :
 
- une classe MyList qui etend JList
- des classes implementant MouseListener et KeyListener pour ta classe MyList
- un ListCellRenderer pour te permettre de modifier a la volée le contenu widget de ta liste. MyCellRenderer qui pourrait etre un JLabel, un JTextField... ou tout autre classe etendant les widget de base. Ca fait quelque chose du style MyCellRenderer extends MyDateJTextField implements ListCellRenderer
 
Avec ca, tu es modulaire car ta liste peut-etre simple ou complexifiée autant de fois que tu veux, en y ajoutant un ch'tit nouveau ListCellRenderer.
 
Any question ??
 
 
 

Ouais, au niveau du modèle. Mais en fait, ton approche très découplée répond, je pense à mon interrogation concernant les méthodes add(), update() et replace() que mon composant doit proposer. Il me parait désormais clair que je dois étendre le DefaultListModel (ou créer un ListModel custom) et y injecter mes méthodes.

Je vois pas trop l'interet d'un composant, mais j'ai peut-etre pas tout compris ... Moi j'utilise un template et je trouve que ca suffit amplement ...
 
 
En parlant de templates, vous connaissez un site ou on recuperer/soumettre des templates ...

Qu'appelles-tu template ?

Ben un squelette de classe.
Pour la JList un truc du genre  

qui construit le scrollpane, ajoute le header, le cellRenderer, le modelMachinTruc, et des squelettes pour les deux derniers ...
 
enfin tous les trucs que tu te tapes a chaque fois quoi ...

Mais c'est contraire à l'idée qui sous-tend la réutilisabilité des objets !

Pour ce qui est du modele, tu peux aussi refaire une ou plusieurs classes de modele. Cependant, la plupart du temps, les simples methodes d'ajout et de suppression heritées du modele de base sont suffisantes. Par contre, si tu veux gerer une liste et a coté un objet representant cette liste en "temps reel" cela peut-etre utile de reecrire ton model)
 

 
Bah, ouais, ca s'appelle le one-shot, c'est pas beau et c'est pas reutilisable... Ca correspond aux personnes pour qui faire de l'objet c'est comme faire du procedural... En gros du moment que j'ai un seul gros objet avec plein de methode dedans, je fais de l'objet...
 
Y'a du boulot...

   
 
Conception objet et patterns objet c'est quand même deux niveaux de maîtrise assez distinct, hein !
 
Bon, enfin pour en revenir au sujet, j'ai finalement choisi de recoder le modèle, pour deux raisons : d'abord parce qu'un Vector en guise de delegate, c'est trop lourd pour mes besoins. Une ArrayList et pouf c'est tout. Secondo, DefaultListModel est une classe méli mélo. Un mix de Collection, Vector et de ListModel... Il y a trois méthodes pour récupérer, trois pour ajouter, trois pour retirer... Voyez vous même l'API, c'est la fête.
 
Là où j'aurais du travail, en fait c'est sur la JList proprement dite. La vue est OK, très bien. Le problème c'est que le MVC utilisé dans Swing est un MVC custom, ou le controller est mixé avec la vue. C'est précisément le controlleur que je vais en partie refaire.

Euh effectivement y'a un trou beant entre design pattern et objet. Quant a savoir si Java est un langage objet...
 
Pour finir, je dirais que parfois c'est pas des masses utile de "refaire la roue"... Tout depend de tes besoins mais pour ce qui est du MVC et sa representation la plus stricte, je suis perplexe quant a son application sur Swing... Swing reste un element de Java que je considere a part et bien que la differenciation vue/controle soit presente, je suis quelque peu perplexe. C'est tellement imbriqué comme fonctionnement (y'a qu'a voir les listener...). Autant je suis d'accord pour appliquer des patterns dans des cas precis (archi repartie par ex ou ca s'applique tres bien), autant swing... Mais bon, ca reste un avis tres personnel, bossant depuis quelques mois sur Swing, j'ai du moi aussi me plier et me resigner a certain "concept".
 
Arf, vivement que je reparte sur de la conception moins bordelique que Swing...
 

En l'occurence : mon besoin est simple : une liste basique dans laquelle j'ajoute des éléments, j'en retire et j'en mets à jour. Le modèle propose cela mais ne me plait guère. En revanche, rien n'est fait concernant la vue : sélectionner automatiquement l'élément qui vient d'être ajouté, sélectionner l'élément d'index n - 1, lors de la suppression de l'élément n... Ce genre de choses que je ne veux coder qu'une fois, pour ensuite utiliser n objets.

Voilà où j'en suis... J'ai pas mal cherché. De partout en vérité. J'ai presque résolu mon problème mais le serpent se mord la queue.
 
Je crée un ListDataListener :
 

 
Ce listener permet de sélectionner un élément particulier de la liste (basé sur son index), en cas d'ajout ou de suppression dans celle-ci.
 
Le problème est que l'initialisation devient plus compliquée :
 

 
Alors qu'avant, sans listener, j'avais :
 

 
Je n'aime pas cette interdépendance que je crée entre la vue et le modèle. Y a t'il une autre solution, plus élégante, qui découple mieux ?

Je me permets de upper, au cas où un monstre en Swing passe dans le coin.

Edit:
En fait ce que j'ai écrit ne marche pas.
 
A mon avis tu peux pas simplifier ce que t'as fait, a part peut etre faire

 
tu gagnes une ligne

J'y avais bien pensé ! C'est plus question design que ça me pose un soucis. Mineur, mais un soucis quand même. Merci de t'être penché sur mon cas, en tous cas.

Je crois que t'as pas tout compris au MVC et aux dépendances mises en jeu.

Tu sors une interface pour ta liste réelle qui sera le modèle.
Tu mets tout le reste dans une classe qui sera une vue avec son contrôleur intégré (cas classique) et ses propres sous-modèles, sous-vues etc.

 
Ah, les grandes phrases qui ne veulent rien dire, merci pour ton humour !! Tu connais au moins la signification de MVC ??
 
Pour finir, t'es pas mal pour proposer "ta" solution ("Tu sors une interface pour ta liste réelle qui sera le modèle" ), mais avant c'est bien aussi de lire tout le topic  
 
Quoiqu'il en soit j'ai bien rigolé, je t'en remercie