Reprise du message précédent :
ca existe aussi avec Vector ...  
m'enfin bref, ceux qui ont compris, ont deja compris
 
the real -- : ca cert a quoi de prototyper quoi que ce soit si tu peux pas l'utiliser apres?!
 
jubijub : bcp (la plupart meme) de compos swing permettent aussi de changer les donnes du modele via le viewer

surtout que la ca ajoutait juste un "new ArrayTableModel()" ... une 20aine de caractères quoi

à faire un prototype ?

(de gui, i.e., un truc qui fait rien a part montrer à quoi la gui pourrait ressembler)

c'est plutot du maquetage nan ?
 
puis bon, l'économie de quelques caractères de code pour un cas d'utilisation rare pour justifier une bizarerie d'une API, ca fait un peu peu ...

 
bah merde :  

 
+1 : un proto c fonctionnel, ou quasiment
une maquette, c comme tu dis --, c juste visuel

En fait moi j'ai utilisé un tableau d'objet pour récupérer les informations sur les tables mysql parce que c'est ce qui me paraissait le plus simple.
Mais si vous pensez que après, avec une autre solution, c'est plus facile, dites le moi, je chercherai sur cette voie.
 
Sinon, à propose du setData, on peut pas utiliser une classe maTable qui hérite de DefaultTableModel et utiliser après le setDataVector? Ensuite ajouter 1 listener sur le changement des valeurs, et pas de la forme, vu que c'est intégré à  un ScrollPane?

-->ben c faire une arrayList d'arrayList...encore que peut etre qu'on peut optimiser ca avec des hashmap avec comme clé les index colone/ligne, je m'y connais pas assez...
 
--> en quoi c différent de ma solution ?

La vache, c'est rapide les réponses sur hardware! Bon, je vais me renseigner pour les araylists.
Sinon, c'est ta solution jubijub, mais avec seulement ce qui m'interesse le plus, pas de d'evolution du contenu mais seulement des données.

On doit pouvoir le rendre plus générique (mais pas au 1.5 ) en faisant que ca prenne une Collection de Collection (Collection étant l'interface qu'implémente Vector, ArrayList, et autre...)
 
--> les données = le contenu, je comprends pas ce que tu veux dire...l'event que je fire prévient le tableau que les données ont changé...
 
edit : pparement pas, l'interface définit pas de méthode pour récupérer le contenu, apparement c propre aux implémentations

ça serait bien qu'il évite les Sets de Sets dans son tableau quand même (ie, List de List au pire, mais plutôt un TableModel fondé sur un DataSet, ça me parraît plus intelligent et moins gourmand en ressources).

pkoi ? c quoi un DataSet ?

ça s'appelle pas DataSet le résultat d'une requête JDBC ?

ResultSet

mais le ResultSet n'est pas idéal à utiliser : t'as pas d'accès direct en x,y

benou > on est pas obligé d'y passer ?

je comprend pas la question. d'y passer à quoi ?

dans le chemin BDD->écran, on est pas obligé de passer par un ResultSet ?

sisi bien sûr.
ce que je voulais dire, c'est que tu ne peux pas faire un TableModel qui se contentera de déleguer les appels au ResultSet, t'es obligé de lire le resultset et de stocker ca dans une Colelction quelconque pour pouvoir reservir les données ...
 
Le seul intérêt que j'y vois c'est de faire du lazy loading, mais ca pause le problême de la connexion à la BDD que tu gardes plus longtemps ...

ah ? c'est pas bien le lazy-loading ? j'aurais crû le contraire (pour répartir doucement le freinage dû au réseau sur le mouvement de scrolling de l'ui en gros).

tout ca pour pas passer par un machin[][] ou un list de list ...

bon, si c'est pas bon de garder le ResultSet trop longtemps, alors le Object[][] (wrappé éventuellement), c'est très bien

tu as des PBs de lecture ?

un ResultSet n'a pas d'api pour recuperer sa taille ....

t'es prof par hasard ou tu bosses dans la recerche ?!

mon entreprise produit 5M d'automobiles par an

ca doit etre a cause des design patterns    
 

ben tu t'en fous, tu scrolles dans ton resultset, tu recuperes, tu caches et en voiture simone, t'es pas obligé de ne faire *que* ce que te demande le get(x,y).

je parle du fait que si tu veux quand meme arriver a un machin[][] il faut d'abord passer par une collection dynamique

un cache oui. tu voudrais pas non plus aller repiocher en base 49 fois pour 7 records de 7 colonnes

spa toi qui aime bien le lazy loading ?
 
edit: merde, confondu avec nraynaud

nraynaud aime tt ce qui est lazy

oué je suis un gros flemmard.

ben c'est lazy, quand tu vas afficher ta table, il va te demander les cellules une par une, et tu vas loader les rows dont tu as besoin au fur et à mesure.

-- > non, parce que le scrollpane va vouloir connaître le preferedSize de sa vue (la JTable) pour calculer la longueur de la barre à afficher, et que pour calculer le preferedSize, il faut connaître la taille du renderer de toutes les cellules et donc les charger toutes.

pis le preferedviewportsize c pratique de la modifier dès que le tableau est initialisé, avant de l'insérer : ca permet de le régler proprement en hauteur, en demandant la hauteur d'une cell, et en multipliant par le nb de cell qu'on veut voir affiché

bah tu peux pas leur donner une valeur fixe et/ou adapter une fois que la premiere page est loadée ?
 
dans le cas d'un browser sql, en general ça t'affiche des largeurs fixes, à l'utilisateur d'adapter celles qu'il veut voir, au besoin..
 
 
 
ou bien rien à voir?

si tu peux spécifier la taille du viewport...mais c assez sale de le faire au début, parce que tu peux etre sur que ta taille sera pas celle du tableau "rempli", et donc tu risque des pbs d'affichage, genre tableau trop grand pour rentrer dans la zone impartie