Je me pose la question de savoir à quoi sert de créer une List<E> = new
ArrayList<E>() pour stocker des objets si on utilise un
DefaultListModel<E> pour représenter une JList<E>? Je pose la question
car, à première vue, le DefaultListModel est une liste en soi. Ou semble-
t-il un Vector... Le DefaultListModel<E> dispose à peu près des mêmes
méthodes que la List<E>. Donc, quel est l'intérêt d'avoir en plus une
List<E>?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Yliur
Le 06 Feb 2018 02:43:18 GMT jp a écrit :
Bonjour, Je me pose la question de savoir à quoi sert de créer une List<E> > new ArrayList<E>() pour stocker des objets si on utilise un DefaultListModel<E> pour représenter une JList<E>? Je pose la question car, à première vue, le DefaultListModel est une liste en soi. Ou semble- t-il un Vector... Le DefaultListModel<E> dispose à peu près des mêmes méthodes que la List<E>. Donc, quel est l'intérêt d'avoir en plus une List<E>? Merci d'avance.
DefaultListModel sert à stocker des données pour l'interface. ArrayList sert à stocker des données en général. En général tes données sont stockées dans des structures comme ArrayList. Puis : - Soit tu veux les copier dans l'interface et qu'elles y soient modifiées sans que la liste d'origine soit immédiatement impactée (jusqu'à une sauvegarde) et dans ce cas tu fais une copie des données dans un modèle destiné à l'interface (DefaultListModel par exemple), puis dans l'autre sens quand tu veux les sauvegarder (pas sur un disque : juste quand tu veux qu'elles soient validées en mémoire). - Soit tu veux que les données de la liste soient modifiées directement via l'interface, auquel cas tu construis un objet de modèle d'une classe à toi qui en fait va modifier ta liste (ArrayList) dès que les modifications sont appliquées dans l'interface. Il existe un troisième cas : - Soit tu ne veux pas faire de distinction entre les données de ton programme et celles affichées dans l'interface, auquel cas tu les stockes directement dans un modèle, par exemple DefaultListModel. Ce n'est a priori intéressant que lorsque les données ne sont pas des données générales manipulées par le programme mais des données qui ne servent qu'à l'interface par exemple. Ou encore si ton programme est vraiment très simple. S'il s'agit des données de ton programme, je te conseille de les stocker dans une liste distincte de l'interface (ArrayList) et de choisir une des deux premières options.
Le 06 Feb 2018 02:43:18 GMT
jp <bloiiing.invalid@yahoo.com> a écrit :
Bonjour,
Je me pose la question de savoir à quoi sert de créer une List<E> > new ArrayList<E>() pour stocker des objets si on utilise un
DefaultListModel<E> pour représenter une JList<E>? Je pose la
question car, à première vue, le DefaultListModel est une liste en
soi. Ou semble- t-il un Vector... Le DefaultListModel<E> dispose à
peu près des mêmes méthodes que la List<E>. Donc, quel est l'intérêt
d'avoir en plus une List<E>?
Merci d'avance.
DefaultListModel sert à stocker des données pour l'interface.
ArrayList sert à stocker des données en général.
En général tes données sont stockées dans des structures comme
ArrayList. Puis :
- Soit tu veux les copier dans l'interface et qu'elles y soient
modifiées sans que la liste d'origine soit immédiatement impactée
(jusqu'à une sauvegarde) et dans ce cas tu fais une copie des
données dans un modèle destiné à l'interface (DefaultListModel
par exemple), puis dans l'autre sens quand tu veux les
sauvegarder (pas sur un disque : juste quand tu veux qu'elles
soient validées en mémoire).
- Soit tu veux que les données de la liste soient modifiées
directement via l'interface, auquel cas tu construis un
objet de modèle d'une classe à toi qui en fait va modifier ta
liste (ArrayList) dès que les modifications sont appliquées dans
l'interface.
Il existe un troisième cas :
- Soit tu ne veux pas faire de distinction entre les données de ton
programme et celles affichées dans l'interface, auquel cas tu les
stockes directement dans un modèle, par exemple DefaultListModel.
Ce n'est a priori intéressant que lorsque les données ne sont pas
des données générales manipulées par le programme mais des données
qui ne servent qu'à l'interface par exemple. Ou encore si ton
programme est vraiment très simple.
S'il s'agit des données de ton programme, je te conseille de les
stocker dans une liste distincte de l'interface (ArrayList) et de
choisir une des deux premières options.
Bonjour, Je me pose la question de savoir à quoi sert de créer une List<E> > new ArrayList<E>() pour stocker des objets si on utilise un DefaultListModel<E> pour représenter une JList<E>? Je pose la question car, à première vue, le DefaultListModel est une liste en soi. Ou semble- t-il un Vector... Le DefaultListModel<E> dispose à peu près des mêmes méthodes que la List<E>. Donc, quel est l'intérêt d'avoir en plus une List<E>? Merci d'avance.
DefaultListModel sert à stocker des données pour l'interface. ArrayList sert à stocker des données en général. En général tes données sont stockées dans des structures comme ArrayList. Puis : - Soit tu veux les copier dans l'interface et qu'elles y soient modifiées sans que la liste d'origine soit immédiatement impactée (jusqu'à une sauvegarde) et dans ce cas tu fais une copie des données dans un modèle destiné à l'interface (DefaultListModel par exemple), puis dans l'autre sens quand tu veux les sauvegarder (pas sur un disque : juste quand tu veux qu'elles soient validées en mémoire). - Soit tu veux que les données de la liste soient modifiées directement via l'interface, auquel cas tu construis un objet de modèle d'une classe à toi qui en fait va modifier ta liste (ArrayList) dès que les modifications sont appliquées dans l'interface. Il existe un troisième cas : - Soit tu ne veux pas faire de distinction entre les données de ton programme et celles affichées dans l'interface, auquel cas tu les stockes directement dans un modèle, par exemple DefaultListModel. Ce n'est a priori intéressant que lorsque les données ne sont pas des données générales manipulées par le programme mais des données qui ne servent qu'à l'interface par exemple. Ou encore si ton programme est vraiment très simple. S'il s'agit des données de ton programme, je te conseille de les stocker dans une liste distincte de l'interface (ArrayList) et de choisir une des deux premières options.
jp
Le Tue, 06 Feb 2018 06:10:45 +0100, Yliur a écrit :
- Soit tu veux que les données de la liste soient modifiées directement via l'interface, auquel cas tu construis un objet de modèle d'une classe à toi qui en fait va modifier ta liste (ArrayList) dès que les modifications sont appliquées dans l'interface.
Merci de ta réponse. J'ai bien compris les différentes possibilités, mais est-ce que tu pourrais préciser un peu plus le point ci-dessus? Par objet de modèle d'une classe entends-tu qu'il faut que j'implémente ma propre version de DefaultListModel à partir de l'interface ListModel?
Le Tue, 06 Feb 2018 06:10:45 +0100, Yliur a écrit :
- Soit tu veux que les données de la liste soient modifiées
directement via l'interface, auquel cas tu construis un objet de
modèle d'une classe à toi qui en fait va modifier ta liste
(ArrayList) dès que les modifications sont appliquées dans
l'interface.
Merci de ta réponse. J'ai bien compris les différentes possibilités, mais
est-ce que tu pourrais préciser un peu plus le point ci-dessus? Par objet
de modèle d'une classe entends-tu qu'il faut que j'implémente ma propre
version de DefaultListModel à partir de l'interface ListModel?
Le Tue, 06 Feb 2018 06:10:45 +0100, Yliur a écrit :
- Soit tu veux que les données de la liste soient modifiées directement via l'interface, auquel cas tu construis un objet de modèle d'une classe à toi qui en fait va modifier ta liste (ArrayList) dès que les modifications sont appliquées dans l'interface.
Merci de ta réponse. J'ai bien compris les différentes possibilités, mais est-ce que tu pourrais préciser un peu plus le point ci-dessus? Par objet de modèle d'une classe entends-tu qu'il faut que j'implémente ma propre version de DefaultListModel à partir de l'interface ListModel?
Yliur
Le 06 Feb 2018 06:22:47 GMT jp a écrit :
Le Tue, 06 Feb 2018 06:10:45 +0100, Yliur a écrit :
- Soit tu veux que les données de la liste soient modifiées directement via l'interface, auquel cas tu construis un objet de modèle d'une classe à toi qui en fait va modifier ta liste (ArrayList) dès que les modifications sont appliquées dans l'interface.
Merci de ta réponse. J'ai bien compris les différentes possibilités, mais est-ce que tu pourrais préciser un peu plus le point ci-dessus? Par objet de modèle d'une classe entends-tu qu'il faut que j'implémente ma propre version de DefaultListModel à partir de l'interface ListModel?
Je voulais dire "tu construis un objet de modèle sous la forme d'une classe à toi". Donc tu définis une classe qui implémente ListModel et tu passeras à la JList un objet de cette classe. Dans cette classe tu aurais un attribut qui référencerait la liste réelle, à passer en paramètre au constructeur, et des méthodes qui redirigent vers cette liste. Pour ça tu peux hériter de AbstractListModel, qui réalise déjà certaines des opérations annexes (gestion des écouteurs d'événements, ...), et implémenter le reste Tu implémentes ça comme le fait DefaultListModel, sauf que c'est une référence à une liste externe. Donc tu dois implémenter la même liste de méthodes que tu trouveras dans la doc de DefaultListModel. C'est vaguement long mais ça devrait être assez simple, de ce type : public void clear () { this.listeDonnees.clear() ; } Si tu utilises Eclipse ou autre environnement de développement intégré, il se peut qu'il y ait une option pour générer une bonne partie de ce code. Par exemple dans Eclipse voir de ce côté : clic droit sur le code source de la classe créée -> Source... -> Generate delegate methods... -> sélecionner celles qui t'intéressent.
Le 06 Feb 2018 06:22:47 GMT
jp <bloiiing.invalid@yahoo.com> a écrit :
Le Tue, 06 Feb 2018 06:10:45 +0100, Yliur a écrit :
> - Soit tu veux que les données de la liste soient modifiées
> directement via l'interface, auquel cas tu construis un objet
> de modèle d'une classe à toi qui en fait va modifier ta liste
> (ArrayList) dès que les modifications sont appliquées dans
> l'interface.
Merci de ta réponse. J'ai bien compris les différentes possibilités,
mais est-ce que tu pourrais préciser un peu plus le point ci-dessus?
Par objet de modèle d'une classe entends-tu qu'il faut que
j'implémente ma propre version de DefaultListModel à partir de
l'interface ListModel?
Je voulais dire "tu construis un objet de modèle sous la forme d'une
classe à toi".
Donc tu définis une classe qui implémente ListModel et tu passeras à la
JList un objet de cette classe.
Dans cette classe tu aurais un attribut qui référencerait la liste
réelle, à passer en paramètre au constructeur, et des méthodes qui
redirigent vers cette liste.
Pour ça tu peux hériter de AbstractListModel, qui réalise déjà certaines
des opérations annexes (gestion des écouteurs d'événements, ...), et
implémenter le reste
Tu implémentes ça comme le fait DefaultListModel, sauf que c'est une
référence à une liste externe. Donc tu dois implémenter la même liste de
méthodes que tu trouveras dans la doc de DefaultListModel. C'est
vaguement long mais ça devrait être assez simple, de ce type :
public void clear ()
{
this.listeDonnees.clear() ;
}
Si tu utilises Eclipse ou autre environnement de développement intégré,
il se peut qu'il y ait une option pour générer une bonne partie de ce
code. Par exemple dans Eclipse voir de ce côté : clic droit sur le code
source de la classe créée -> Source... -> Generate delegate methods...
-> sélecionner celles qui t'intéressent.
Le Tue, 06 Feb 2018 06:10:45 +0100, Yliur a écrit :
- Soit tu veux que les données de la liste soient modifiées directement via l'interface, auquel cas tu construis un objet de modèle d'une classe à toi qui en fait va modifier ta liste (ArrayList) dès que les modifications sont appliquées dans l'interface.
Merci de ta réponse. J'ai bien compris les différentes possibilités, mais est-ce que tu pourrais préciser un peu plus le point ci-dessus? Par objet de modèle d'une classe entends-tu qu'il faut que j'implémente ma propre version de DefaultListModel à partir de l'interface ListModel?
Je voulais dire "tu construis un objet de modèle sous la forme d'une classe à toi". Donc tu définis une classe qui implémente ListModel et tu passeras à la JList un objet de cette classe. Dans cette classe tu aurais un attribut qui référencerait la liste réelle, à passer en paramètre au constructeur, et des méthodes qui redirigent vers cette liste. Pour ça tu peux hériter de AbstractListModel, qui réalise déjà certaines des opérations annexes (gestion des écouteurs d'événements, ...), et implémenter le reste Tu implémentes ça comme le fait DefaultListModel, sauf que c'est une référence à une liste externe. Donc tu dois implémenter la même liste de méthodes que tu trouveras dans la doc de DefaultListModel. C'est vaguement long mais ça devrait être assez simple, de ce type : public void clear () { this.listeDonnees.clear() ; } Si tu utilises Eclipse ou autre environnement de développement intégré, il se peut qu'il y ait une option pour générer une bonne partie de ce code. Par exemple dans Eclipse voir de ce côté : clic droit sur le code source de la classe créée -> Source... -> Generate delegate methods... -> sélecionner celles qui t'intéressent.
jp
Le Tue, 06 Feb 2018 17:22:38 +0100, Yliur a écrit :
Le 06 Feb 2018 06:22:47 GMT jp a écrit :
Le Tue, 06 Feb 2018 06:10:45 +0100, Yliur a écrit :
Si tu utilises Eclipse ou autre environnement de développement intégré, il se peut qu'il y ait une option pour générer une bonne partie de ce code. Par exemple dans Eclipse voir de ce côté : clic droit sur le code source de la classe créée -> Source... -> Generate delegate methods... -> sélecionner celles qui t'intéressent.
OK. J'ai compris. Je vais finir par y arriver...:) Merci beaucoup.
Le Tue, 06 Feb 2018 17:22:38 +0100, Yliur a écrit :
Le 06 Feb 2018 06:22:47 GMT jp <bloiiing.invalid@yahoo.com> a écrit :
Le Tue, 06 Feb 2018 06:10:45 +0100, Yliur a écrit :
Si tu utilises Eclipse ou autre environnement de développement intégré,
il se peut qu'il y ait une option pour générer une bonne partie de ce
code. Par exemple dans Eclipse voir de ce côté : clic droit sur le code
source de la classe créée -> Source... -> Generate delegate methods...
-> sélecionner celles qui t'intéressent.
OK. J'ai compris. Je vais finir par y arriver...:)
Le Tue, 06 Feb 2018 17:22:38 +0100, Yliur a écrit :
Le 06 Feb 2018 06:22:47 GMT jp a écrit :
Le Tue, 06 Feb 2018 06:10:45 +0100, Yliur a écrit :
Si tu utilises Eclipse ou autre environnement de développement intégré, il se peut qu'il y ait une option pour générer une bonne partie de ce code. Par exemple dans Eclipse voir de ce côté : clic droit sur le code source de la classe créée -> Source... -> Generate delegate methods... -> sélecionner celles qui t'intéressent.
OK. J'ai compris. Je vais finir par y arriver...:) Merci beaucoup.
