[JAVA]Jtable en Foxtrot werkt niet goed

[MeIsTwisted]

Ik ben bezig met een projectje en gebruik daarin in ook JTables. Hierdoor wordt de GUI ontzettend traag, dus ik wilde met Foxtrot het sneller maken.

De bottleneck zit volgens mij in de getValueAt methode in het tableModel, dus hier heb ik een foxtrot job gemaakt. Dit werkt alleen niet goed, want ik krijg allemaal foutmeldingen als ik ga scrollen (stackoverflow), of GUI wordt helemaal vergald.

Ik kom er alleen niet achter wat nou precies fout gaat, of hoe ik het wel goed kan krijgen, zodat GUI wel snel gaat.

hier de code van getValueAt:

Java:

        public Object getValueAt(final int row, final int col){
            Object o = (Object)Worker.post(new Job(){
                public Object run(){
                    Workshop w = (Workshop)(workshops.elementAt(row));
                    switch(col){
                        case WS_NAAM_COL : return w.getNaam();
                        case WS_PRIJS_COL : return new Double(w.getKosten());
                        case WS_DOCENT_COL : return w.getDocent();
                        case WS_DAGDEEL_COL : return w.getDagdelen();
                        case -1: return new Integer(w.getId());
                    }
                    return new String();
                }
            });
            return o;
        }

[Alarmnummer]

Hoeveel workshops heb jij in die tabel staan? Ik heb regelmatig grote hoeveelheiden info in de JTable staan, en dat gaat op zich niet echt traag. Dus als het er minder dan een paar 100 zijn, dan is er iets aan de hand.

Werk de code wel als je het even zonder foxtrot doet?

[MeIsTwisted]

jah, dan werkt wel.
Ik heb de andere klassen eens zitten kijken en ik weet nu wel hoe het komt.

In de andere klassen wordt bij de getMethode rechtsteeks iets uit de databse gehaald. 30 workshops x 4 eigenschappen is heel veel queries.

De klassen moeten gewoon herschreven worden, dat niet bij elke get uit de db wordt gevist. Dit had ik ze al gezegd, maar ze wilden altijd de laatste data hebben en icm tableModel is dat niet zo lekker.

Ik ga dus wel omgooien.

Ik heb net getest door de getMethodes te vervangen door "gewone" waardes en toen ging wel snel. Wisten voordat we de GUI gingen bouwen niet dat swing zo werkte met listModels. niet zo slim dus

[Alarmnummer]

Gebruiken jullie trouwens ook een or-mapper of doen jullie het met de hand?

[MeIsTwisted]

Alarmnummer schreef op 14 mei 2004 @ 11:23:
Gebruiken jullie trouwens ook een or-mapper of doen jullie het met de hand?

wat bedoel je daarmee?

[Alarmnummer]

MeIsTwisted schreef op 14 mei 2004 @ 11:25:
[...]
wat bedoel je daarmee?

Tikken jullie zelf de sql-queries of heb je een tool die er voor zorgt dat al je java objecten naar een relationeel db komen, en andersom.

[MeIsTwisted]

Alarmnummer schreef op 14 mei 2004 @ 11:26:
[...]

Tikken jullie zelf de sql-queries of heb je een tool die er voor zorgt dat al je java objecten naar een relationeel db komen, en andersom.

tikken zelf de queries

[Alarmnummer]

MeIsTwisted schreef op 14 mei 2004 @ 11:35:
[...]
tikken zelf de queries

Anders moet je eens kijken naar or-mapper, bv hibernate, jdo, of ojb. Een goeie or-mapper is erg lastig om te schrijven. Hoe garandeer je bv dat er niet meerdere instanties van dezelfde entiteit in je geheugen komt. Dus misschien meerdere alarmnummer objecten in je geheugen. Hoe ga je verder om met die enorme lading database communicatie dat jullie veroorzaken. Ga je veld voor veld ophalen, of record voor record? Hoe ga je om met de relaties tussen objecten, bv alarmnummer.getMoeder(). Stel dat je zo vriendelijk bent om dan ook meteen maar mijn moeder in te lezen, dan zul je ook haar moeder moeten inlezen. Als je niet oppast trek je dus met een enkele read de hele database in je geheugen. En dan heb ik het nog niet eens gehad over alle problematiek rond transacties. Stel dat je voor een of andere object update 10 objecten moet aanpassen, en dat je halverwege je update faalt. Wat dan? Dan zijn 5 objecten goed aangepast, en 5 niet.

Patterns of Enterprise application architecture van Martin Fowler gaat hier erg diep op in en is een absolute aanrader.