[JList] Comment ça marche ?

Bonjour,
Malgré la lecture des tutoriels de Sun et de multiple recherches sur le forum, je n'arrive toujours pas à comprendre le fonctionnement de la JList. :oops:
En fait, ce qui me pose problème c'est le rafraichissement de la JList après modification du modèle.
Tout d'abord quelle est la meilleure manière de créer un modèle ?

• implémenter ListModel
• étendre AbstractListModel
• ou bien, étendre DefaultTableModel ?

ensuite, après modification du modèle, comment mettre à jour la JList: updateUI, revalidate(),...?

Merci d'avance pour votre aide ;)

Je ne suis pas sûr de pouvoir répondre à ta question.

MAIS (oui, il y a toujours un "mais").

j'utilise de temps en temps le modèle MVC (surtout modèle et vue, donc ce qui te concerne) sur des JTable.

En général, je créée une classe qui hérite de DefaultTableModel (qui est une classe, attention : pas une interface) et ensuite j'attribue ce modèle à ma JTable grâce à :

Citation:

---

void setModel(TableModel dataModel)
Sets the data model for this table to newModel and registers with it for listener notifications from the new data model.

---

(méthode de JTable).

Une fois que le modèle change .... (aïe, là j'ai honte) ... je refais un setModel(...).

Je te l'accorde, c'est plutôt crade comme manière de l'utiliser ... mais ça a l'avantage de fonctionner.

Après quelques recherches suite à ton message, j'aurais tendance à utiliser revalidate() car la définition de updateUI est :

Citation:

---

Notification from the UIManager that the L&F has changed. Replaces the current UI object with the latest version from the UIManager.

---

Ce qui n'est pas ton cas : c'est le modèle qui a changé.

J'espère avoir pu t'aider un tout petit peu ...

Bonjour,

implémenter directement ListModel est un peu tendu, notamment parce qu'il faut gérer les modifications soi-même.

En étendant AbstractListModel, il suffit d'appeler les méthodes fire... à chaque modification des données.

En étendant DefaultListModel, il faut passer par les méthodes fournies, ou, si on les surcharge, appeler super.methode() ou le fire... approprié.

Ces méthodes fireContentsChanged(), fireIntervalAdded(), fireIntervalRemoved() font tout ce dont tu as besoin, donc pas la peine de réinventer la roue.

bonjour,
Merci pour vos reponses mais j'ai d'autres questions:
Faut-il alors ajouter explicitement la JList comme listener du modèle ?
Faut-il appeler les trois méthodes à chaque changement du modèle ?

Citation:

---

Envoyé par afrikha

Faut-il alors ajouter explicitement la JList comme listener du modèle ?

---

Il ne me semble pas. Il faut simplement fournir le modèle comme paramètre du constructeur de la JList.

Citation:

---

Envoyé par afrikha

Faut-il appeler les trois méthodes à chaque changement du modèle ?

---

Non, seulement celle qui est la plus appropriée.
Ajout d'une ligne à l'index 3 : -> fireIntervalAdded(this, 3, 3);
Suppression des lignes 0 à 3 -> fireIntervalRemoved(this, 0, 3);
Ajout de 3 lignes à des endroits différents et suppression de 5 lignes : fireContentsChanged sera plus simple qu'une dizaine de fireIntervalAdded/Removed.


Si tu ne veux pas t'embêter à savoir laquelle appeler, tu peux faire fireContentsChanged(this, 0, getSize() - 1); mais ce n'est pas optimal.

Je trouve que le tuto de sun sur les liste est assez clair...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

// On déclare le modèle // DefaultListModel est implementation de 'linterface ListModel DefaultListModel monModeleDeListe = new DefaultListModel();   // On déclare la liste avec le modèle Jlist maListe = new JList(monModeleDeListe);   // On travaille sur le modèle pour le traitement // Et sur la JList pour l'interaction monModeleDeListe.addElement("Ligne 1."); int index = maListe.getSelectedIndex(); monModeleDeListe.remove(index);

---

je sais qu'en théorie, dans le modèle Modèle Vue Contrôleur, la vue est updatée par défaut lors du changement du modèle.

Est-ce vraiment le cas ?
Il me semble que non ..... et j'ai trop la flemme de faire 10 lignes de code pour ça :oops:

Il me semble que pour certains de mes projets, j'ai été obligé de commander le rafraichissement (en l'occurence par une ré-attribution du modèle à la vue).
Je m'y suis peut-être tout simplement mal pris ....

Si quelqu'un a une réponse ... :P

pour des application client je prefere utiliser le MVP au MVC.
c'est plus adapter.
Martin Fowler explique pourquoi dans sont livre "Patterns of Enterprise Application Architecture"

et le 'P' signifie ?

Citation:

---

Envoyé par NeptuS

Il me semble que pour certains de mes projets, j'ai été obligé de commander le rafraichissement (en l'occurence par une ré-attribution du modèle à la vue).
Je m'y suis peut-être tout simplement mal pris ....

---

C'est en effet pas la meilleure méthode. En passant par les méthodes du DefaultListModel, ça gère le rafraîchissement. Ou en utilisant AbstractListModel, en appelant les fireMachin. Ou en faisant je ne sais pas quoi avec un TableModel.

> et le 'P' signifie ?

Model View Presenter.

Martin Fowler explique ca dans son livre
Karsten Lentzsch l'utililse aussi. je crois qui y a meme une presentation sur son site. Son JGoodies Binding est concu en MVP ;-)

merci bbclone.

xavlours, comme je l'ai dit plus haut, je travaillais surtout sur des JTable dont le mode de fonctionnement est aussi MVC ; et je créais un DefaultTableModel (ou alors je le surchargeais, ça dépend).

mais je me trouvais tout de même avec des problèmes de raffraichissement.

> JTable dont le mode de fonctionnemtn est aussi MVC

c'est pas tous a fais juste.
swing n'est pas tous a fais mvc....

attent j'ai lus un article sur tss il y a quelque temp.

http://www.theserverside.com/tt/arti...s?l=JavaGUIDev
et
http://www.theserverside.com/news/th...hread_id=30278

et je conseille a tous de lire le livre de Martin Fowler. Ca donne un bon apercu de comment on doit architecturer des applications client et aussi web.

En fait swing est basé sur une architecture Model + (Vue-Controleur)

Dans le cas présent la JTable est à la fois Vue et Contrôleur mais possède une modèle séparé