Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Vector déconseillé -> avec quoi utiliser DefaultTableModel (par exemple) ?
Comme dit dans le titre, l'utilisation de Vector est déconseillée.
Manque de bol, je développe une appli avec plein de tableModel basés sur... des Vector ! Je sais qu'on peut utiliser des tableaux, mais c'est vraiment pas pratique.
Quelqu'un aurait il donc une alternative avec des ArrayList ou qqchose dans le genre ?
Un Arraylist est l'équivalent d'un Vector, sauf que l'ArrayList n'est pas
Thread safe.
Tu peux donc remplacer tes Vector facilement.
On s'est pas bien compris... les contructeurs de Model prennent généralement en paramètre des Vector et leur contenu est généralement des Vector (voir http://java.sun.com/j2se/1.4.2/docs/...ableModel.html). C'est de ça que je parle.Envoyé par fr1man
Je suis donc obligé de faire new DefaultTableModel( monVectorData, monVectorColumnNames ) et vu que les Vector sont déconseillés, ben voilà quoi...
Disons que dans mon cas, je me crée mon propre Model qui utilise une
ArrayList.
OK. Jvoulais savoir si il existait pas un truc déjà tout fait.
salut,
moi quand j'utilise des tableaux en général je crée une classe héritant de DefaultTableModel, je lui passe une liste de données
et dans cette classe je redéfinis les méthodes getValueAt, getColumName, getClass.... je n'ai pas mon code sous les yeux mais c'est ca.
en fait la liste que tu passe en paramètre par exemple au constructeur de ta nouvelle classe c'est une liste d'objet User, donc pour un getValueAt(column, row) tu fais par exemple User user = list.get(row);
if (colum == NOM)
return user.getNom();
else if ....
et ton NOM est un define correspondant au numéro de la colone.
la méthode getClass je crois renvoi elle la classe que contiendra ta cellule ou ta colonne, cela lui permet de préparer l'editor de ta cellule...
voila mais ya pas mal de tutorials sur ca.... je crois
bon courage
sinon tu peux remarquer que si chaque tableau est différent tu aura une classe pour chaque tableModel correspondant....
C'est bon en fait, je me suis fait mon propre model pour JTable basé sur des ArrayList.
Je le partage en pièce jointe, dites moi si y'a des bugs
Bien d'accord avec schniouf
J'ai eu exactement la même réflexion sur : Vector + tableModel.
Je veux bien me passer de Vector pour un ArrayList mais quelqu'un peut-il m'expliquer pourquoi il faut abandonner la classe Vector ? Est-elle :
- pas fiable ?
- pas pratique ?
- politiquement incorrecte ?
- bourrée d'amiante ?
Labor improbus omnia vincit un travail acharné vient à bout de tout - Ambroise Paré (1510-1590)
Consulter sans modération la FAQ ainsi que les bons ouvrages : http://jmdoudoux.developpez.com/cours/developpons/java/
Tu aurais pu bosser avec un ArrayList et faire un 'toArray()' au moment de passer ton ArrayList au constructeur.
Salut,
La classe Vector n'est pas déconseillé !!! Il faut juste lui préféré ArrayList lorsque c'est possible...
Vector et ArrayList ont une implémentation très proche (basé sur l'utilisation d'un tableau en interne), et il y a principalement deux "différences" entre les deux :C'est pour cela qu'il faut en général lui préférer la classe ArrayList... Toutefois Vector n'est pas déconseillé car elle est encore énormément utilisé (en particulier dans Swing), et ce n'est pas la peine de se triturer l'esprit pour éviter de l'utiliser...
- Vector existait avant l'apparition de l'API de Collection, elle possédait ainsi ses propres méthodes et a été adaptée afin de respecter les interfaces de cette nouvelle API (Collection et List). Du coup elle possède quelques méthodes en doublons (comme addElement() et add() ou elementAt() et get()) qui la rendent plus complexe...
- Vector est thread-safe. C'est à dire que ses méthodes sont synchronizées et que la classe peut être utilisé depuis différents thread sans poser de problème. Or avec l'API de Collection, les différentes implémentations ne sont pas thread-safe par défaut (pour de meilleures performances en mono-thread, même si les différences sont minime), mais peuvent le devenir via les méthode synchronizedCollection() de la classe Collections. Du coup Vector sort un peu de cette logique...
Dans ce cas précis il vaut largement mieux utiliser un Vector avec un DefaultTableModel plutôt que de se réécrire sa propre implémentation de TableModel (au passage la méthode setValueAt() est incorrecte car elle ne renseigne pas ses listeners).
a++
Répondre avec citation
Partager