TableModelEvent ermitteln

[Gast]

So ich hab mal ne frage und hoffe diese halbwegs verständlich formulieren zu können.

Also ich habe ein Frame wo eine JTable exestiert, welche mittels ResultSet gefüllt wird.
Dazu hab ich nen eigenes TableModel, welches von dem AbstractTableModel abgeleitet wird.

So in diesem Model habe ich in zwei verschiedenen Methoden ein Fire von einem Event.. Einmal StructureChanged und einmal TableChanged.

So nun hab ich auf diesem Model ein ActionListener im Frame.

Wenn nun im Model ein Event gefeuert wird (eine der beiden FireMethoden), wird der TableModelListener im Frame aktiv..

soweit alles wie gewünscht..

Nun zu meiner Frage:

Wie kann ich im Listener nun herausfinden welches Event gefeuert wurde? Möchte dies nur ungern mit externen Variablen setzten um diese dann abzufragen.

Gibt es da eine Möglichkeit z.b. abzufragen welches Event aktiv ist? Ob das nun z.b. ein StructureChange ist oder etwas anderes?


LG

 

[thE_29]

Du kriegst ja nen ActionEvent e mit, den mal genauer anschauen!

 

[dope]

ups als gast gestartet.. naja ich bin der Gast.



b2t:

das ist richtig..

hab aber schon fast alles mit e ausprobiert.. getSource etc, aber entweder sind die werte aller events gleich oder die benutze funktion ist einfach falsch.

muss ich vielleicht andere events verwenden?

hat das jemand schonmal so realisiert, oder gibt es da ein geschickteres vorgehen?

 

[dope]

so hab es hinbekommen.

Die beiden von mir verwendeten Fire Methoden haben die selbe Wertigkeit gehabt. Beide 0.
Hab nun eine andere Fire Methode genommen, die mir -1 liefert.

Nun lassen sich die beiden unterscheiden und im Listener gezielt abfragen.

lg

dope

 

[André Uhres]

..Dazu hab ich nen eigenes TableModel, welches von dem AbstractTableModel* abgeleitet wird..

*Tipp: Die direkte Ableitung von AbstractTableModel ist schlechter Stil, denn OOP empfiehlt den Gebrauch von DefaultTableModel.

 

[Beni]

André: hä? Wieso soll das schlechter Stil sein? Das AbstractTableModel existiert doch gerade deshalb, damit man leicht ein eigenes schreiben kann. ???:L

 

[André Uhres]

André: hä? Wieso soll das schlechter Stil sein? Das AbstractTableModel existiert doch gerade deshalb, damit man leicht ein eigenes schreiben kann. ???:L

Naja, ich kann mich nicht unbedingt als OOP Shamanen bezeichnen (um eine Vokabel von Leroy aufzugreifen).
Aber ich glaube, daß professionelle OOP-Entwickler nie zögern werden, die Arbeit anderer wiederzuverwenden,
solange sie ihren Anforderungen entspricht, von hoher Qualität ist, sowie gut dokumentiert und leicht verständlich ist.
Das "NIH-Syndrom" ist wohl eine Legende (Not Invented Here).
Wenn dieses Syndrom wiklich existieren würde, dann würden objektorientierte Entwicklungsumgebungen nicht mit
Klassenbibliotheken aufwarten, und die hunderten von Firmen, die wiederverwendbare Komponenten und Frameworks
verkaufen, gäbe es dann auch nicht.
(Btw: DefaultTableModel ist eine Erweiterung von AbstractTableModel und entspricht sicherlich professionellen Ansprüchen).

 

[L-ectron-X]

Ich hab meine eigenen TableModels auch bisher immer von AbstractTableModel abgeleitet.

 

[André Uhres]

Ich hab meine eigenen TableModels auch bisher immer von AbstractTableModel abgeleitet.

Ja gut, das mach ich ja auch.
Nur mach ich's nicht direkt von AbstractTableModel, sondern indem ich dessen Erweiterung,
DefaultTableModel wiederverwende und gegebenenfalls erweitere.
So nutze ich den bereits bestehenden tollen Code und muss nicht ne Menge neu erfinden

 

[Illuvatar]

Das DefaultTreeModel ist eben schon um einiges spezieller als das abstrakte...

 

[André Uhres]

Das DefaultTreeModel ist eben schon um einiges spezieller als das abstrakte...

Naja, "spezieller" ist wahrscheinlich nicht der richtige Ausdruck:
DefaultTableModel (das meinst du ja wohl) ist einfach "nützlicher" als sein Vater
und bleibt dabei genauso flexibel, da man seine Methoden ebenfalls überschreiben kann.
DefaultTableModel ist also in jedem Fall vorzuziehen.

 

[Beni]

Nach dieser Logik müsste man aber immer von der untersten Klasse einer Klassenhierarchie ableiten.
IMHO: Je tiefer unten man in der Hierarchie ist, desto spzialisierter sind die Klassen. Irgendwann ist man so spezialisiert, dass es nicht mehr zur Aufgabe passt, die man lösen möchte. Deshalb kann (muss aber nicht!) es Sinn machen, auchmal direkt von AbstracTableModel zu erben.

 

[André Uhres]

Nach dieser Logik müsste man aber immer von der untersten Klasse einer Klassenhierarchie ableiten.
IMHO: Je tiefer unten man in der Hierarchie ist, desto spzialisierter sind die Klassen. Irgendwann ist man so spezialisiert, dass es nicht mehr zur Aufgabe passt, die man lösen möchte. Deshalb kann (muss aber nicht!) es Sinn machen, auchmal direkt von AbstracTableModel zu erben.

Ich will ja gar nicht verallgemeinern. Aber im Fall von DefaultTableModel wäre es tatsächlich sinnlos direkt vom Vater abzuleiten.
Der muss ja dann das, was der Sohn schon längst kann, erstmal selbst lernen.
Das wäre aber schlechter Stil, denn man sollte ja, soweit wie möglich, bestehenden Code nutzen.
Und wer mit JTable arbeitet, der kommt in der Hinsicht nicht an DefaultTableModel vorbei.

 

[Roar]

DefaultTableModel kann nicht mehr als AbstractTableModel außer, dass es mit diese Vectoren zur datenhaltung aufzwingt. wenn ich also woanders meine daten halte als in vectoren, was ja irgendwie immer der fall ist, muss ich entweder was schreiben um meine daten in die vectoren vom defaulttablemodel zu packen oder ich überschreibe alle methoden im defaulttablemodel, welche die daten auslesen, und biege die auf mein model um, und dann bleibt mir vom dtm nich mehr als mit das abstracttablemodel bietet :roll:

sogar im sourcecode in DTM steht:

	// Sometimes the DefaultTableModel is subclassed 
	// instead of the AbstractTableModel by mistake.

:lol:

 

[André Uhres]

DefaultTableModel kann nicht mehr als AbstractTableModel ..

DTM kann selbstverständlich viel mehr als ATM, da kann nun wirklich niemand das Gegenteil behaupten :wink:
Wie kommst du nur auf die Sache mit den Vectoren? Vectoren werden in keiner Weise aufgezwungen :wink:
Der Kommentar aus dem Code von DTM ist im Zusammenhang zu lesen,
und hat dann eine ganz andere Bedeutung, ausserdem steht da ja eh nur "Sometimes" :wink:

 

[Roar]

ne, das einzige was das dtm mehr kann sind die vectoren, und die methoden um diese vectoren zu verändern. wenn ich die vectoren über bord werfe bietet mir das dtm nicht mehr als das atm

 

[André Uhres]

..die methoden um diese vectoren zu verändern..

Das ist ein wesentlicher Teil der Table-API, kann man unmöglich als Nebensache betrachten.

 

[Illuvatar]

Das ist ja auch klar, und es kann häufig nützlich sein. Aber genauso häufig kann es auch total unnütz sein. Wenn du eine TableModel schreibst, dass direkt mit ner DB interagiert, brauchst du das Zeugs aus DefaultTableModel nicht. Und vielleicht willst du ja so Methoden wie addColumn/addRow auch nicht haben...

 

[André Uhres]

..genauso häufig kann es auch total unnütz sein..

Das ist wohl übertrieben ausgedrückt, solche Fälle sind eher Ausnahmen.
Ansonsten ist DefaultTableModel immer zu bevorzugen.