[JAVA] DefaultTableModel met vectoren

[Verwijderd]

Hallo,

Ik ben bezig met een jtable met een DefaultTableModel die gebruik dient te maken van 2 vectoren.

Sun vindt dat ik het zo zou moeten doen:

DefaultTableModel(Vector data, Vector columnNames)
Constructs a DefaultTableModel and initializes the table by passing data and columnNames to the setDataVector method.

Op het moment dat ik echter 2 vectoren meegeef krijg ik een java.lang.ClassCastException foutmelding.

AARGH.....

Omdat ik aan het testen ben hiermee, zijn mijn vectoren nou ook niet echt zeer boeiend te noemen.

Vector temp = new Vector();
temp.add("1");
temp.add("2");
temp.add("3");
temp.add("4");
temp.add("5");

Vector temp2 = new Vector();
temp2.add("id");

Onderstaande code gaat nu echter fout.

DefaultTableModel dtm = new DefaultTableModel(temp, temp2);
tabel = new JTable(dtm);
tabel.createDefaultColumnsFromModel();
jScrollPaneel = new JScrollPane(tabel);

Wat doe ik fout?

[kenneth]

De Vector data moet Vectors bevatten naar de data, dus niet de data zelf.

Bijvoorbeeld:

Java:

    Vector temp = new Vector();
    for (int i=0; i < 10; ++i) {
        Vector v = new Vector();
        v.add(Integer.toString(i));
        temp.add(v);
    }

[ Voor 11% gewijzigd door kenneth op 07-05-2003 18:09 ]

[mbravenboer]

Waren er nu maar vast geparameterizeerde typen ... Dat had weer een topic gescheeld .

[Verwijderd]

kenneth schreef op 07 May 2003 @ 18:08:
De Vector data moet Vectors bevatten naar de data, dus niet de data zelf.

Bijvoorbeeld:

Java:

    Vector temp = new Vector();
    for (int i=0; i < 10; ++i) {
        Vector v = new Vector();
        v.add(Integer.toString(i));
        temp.add(v);
    }

Euh, bedankt, maar ik vind wel dat JAVA dit niet echt mooi doet.
Ben ik nu gek als ik denk dat dit binnen know time superveel geheugen opvreet?

[mbravenboer]

Deze aanpak is juist fantastisch .

Het heet niet voor niets een DefaultTableModel. Dit is een standaard implementatie die je kan gebruiken en dan de data op een bepaalde manier vereist. In bijna alle situaties wil je echter een eigen TableModel implementatie maken. Typisch extend je dan AbstractTableModel.

Misschien is de term default overigens wel wat verwarrend ja... Misschien had het beter IfYouReallyDontGetMVCTableModel kunnen heten .

[hobbit_be]

mbravenboer schreef op 07 May 2003 @ 18:27:
Deze aanpak is juist fantastisch .

ik geef niet graag toe dat er iets goed in Swing is maar dit is zo'n geval waar het wel goed zit . Alleen de complete seperatie van ColumnModel en zo slaat op niets (ie de columnNames zitten in table model dan weer ander spul anders).

MVC ROCKS! (alleen jammer dat Swing niet MVC genoeg is - al die models zit net iets anders in elkaar - geen enkel is een instance v/e ander alsof ze allemaal geen 'modified' nodig zouden hebben)...

[mbravenboer]

hobbit_be: Alleen de complete seperatie van ColumnModel en zo slaat op niets (ie de columnNames zitten in table model dan weer ander spul anders).

Ik had daar eigenlijk juist graag een volkomen scheiding gezien. Ik implementeer het dus ook altijd volledig gescheiden. Ik had weleens commentaar geleverd op de rare vermeninging die in feite dubbelop is. Als reactie (van een Swing topper, Hans Muller) kreeg ik dat dat noodzakelijk is om default kolom namen te kunnen gebruiken .

alleen jammer dat Swing niet MVC genoeg is

Ik denk dat je meerdere lagen van modellen nodig hebt. De Swing modellen zijn erg sterk gebonden aan een specifiek GUI component en dat is eigenlijk niet de bedoeling. Toch functioneren ze best goed als modellen, maar juist als modellen voor die GUI componenten. Op andere niveaus heb je ook modellen nodig, die GUI component onafhankelijk zijn. Je kan de modellen van Swing zelf implementeren op basis van die modellen op een lager niveau.

[hobbit_be]

mbravenboer schreef op 07 May 2003 @ 18:49:
[...]
Ik had daar eigenlijk juist graag een volkomen scheiding gezien. Ik implementeer het dus ook altijd volledig gescheiden. Ik had weleens commentaar geleverd op de rare vermeninging die in feite dubbelop is. Als reactie (van een Swing topper, Hans Muller) kreeg ik dat dat noodzakelijk is om default kolom namen te kunnen gebruiken .
[...]
Ik denk dat je meerdere lagen van modellen nodig hebt. De Swing modellen zijn erg sterk gebonden aan een specifiek GUI component en dat is eigenlijk niet de bedoeling. Toch functioneren ze best goed als modellen, maar juist als modellen voor die GUI componenten. Op andere niveaus heb je ook modellen nodig, die GUI component onafhankelijk zijn. Je kan de modellen van Swing zelf implementeren op basis van die modellen op een lager niveau.

ja - ofwel gescheiden ofwel tesamen maar niet een beetje dat kwam niet goed over. waarom was dat nodig? een Table heeft toch de twee ? (ie het is de 'glue', misschien hadden ze beter een echt TableModel genoemen met daarin 'ColumnModel' 'DataModel'... )

idd van die meerdere model ben ik 100% akkoord - voor ons project doen we bijna niets anders dan alle UI naar een 'unifrom' patroon te gooien. Ook met al die events ben ik niet akkoord. Maar het 'lack' (nederlands ? ) aan interfaces vind ik toch erg - erg We zullen maar wachten op Swing v2 and Java 1.5