Events nicht an aufrufendes Objekt schicken

[Elephant]

Hallo,

ist es schlechter Stil, wenn man einer Methode eines Objekts mitgibt, wer die Methode aufgerufen hat.

Z.B. über eine JTable kann ich Objekte ändern. Wenn ein Objekt geändert wird, schickt es ein Event an alle Objekte, die es beobachten, dazu gehört auch die JTable.

Die JTable muss dann erst das Objekt raussuchen, das geändert wurde und dann die Ansicht aktualisieren. Das dauert bei sehr vielen Objekten. Da aber die JTable ja die Änderungsaktion ausgeführt hat könnte ich dort gleich per TableModelEvent die richtige Zeile (bzw. Zeilen bei mehreren Änderungen) schicken, da ich sie dort noch weiß.

Also wäre es gut, wenn das Objekt an alle Beobachter eine Nachricht schickt, dass es geändert wurde, nur nicht an die JTable (bzw. das Model der JTable oder andere Objekte, die es beobachten), die es geändert hat. Dazu müsste das Objekt immer wissen wer eine Methode aufgerufen hat.

Kann man das so machen oder ist das völliger Blödsinn?

 

[Sky]

Was für Events schickst Du an wen und warum ?

Geht es hier um Observer oder sowas ?

 

[Mag1c]

Hi,

also die JTable ist dahingehend schon optimiert worden. Wenn die richtigen Events verschickt werden, werden auch nur die betroffenen Zellen aktualisiert. Wenn das zu lange dauert, dann werden entweder die falschen Events geschickt (fireTableDataChanged() ist hier ein heißer Kandidat ) oder es dauert eben so lange. Wenn du keine Events schickst, werden die Zellen nicht aktualisiert.

Gruß
Mag1c

 

[Elephant]

Mmh, also das Problem ist eigentlich, dass die JTable und auch alle anderen Views (von denen es einige gibt) alle das gleiche Model verwenden.

D.h. es gibt Buch-Objekte, die in einer ArrayList stehen, die ein Bibliotheks-Objekt als Variable enthält. Jede Zeile der JTable stellt jetzt ein Buch-Objekt dar. Wenn ich eine Zelle der JTable ändere wird über die setMethode bei dem entsprechenden Buch-Objekt die Variable geändert. Dann schickt das Buch-Objekt eine Nachricht an alle anderen Objekte, die bei ihm als Listener angemeldet sind.

D.h. wenn ich bei der JTable was ändere, reicht es nicht, wenn ich dort nur ein TableModelEvent schicke, denn dann wird nur die JTable aktualisiert. Es gibt aber noch andere Views, die auch ein Buch-Objekt oder mehrere darstellen, die von der Änderung informiert werden müssen. Also schickt das Buch-Objekt, dass geändert wird, die Nachricht an seine Listener.

Das heißt momentan schick ich nicht direkt ein TableModelEvent vom TableModel aus an die JTable wenn ich per setValue() etwas ändere, sondern ich höre auf die Buch-Objekte, die bei einer Änderung eine Nachricht schicken. Und im TableModel muss dann das Buch-Objekt rausgesucht werden und dann ein TableModelEvent abgeschickt werden.

Das ist wahrscheinlich nicht besonders gut zu verstehen und ziehmlich umständlich, deshalb frage ich, obs eine einfache Lösung gibt.

Die Events schicke ich also vom Buch-Objekt aus, wenn sich dort eine Variable ändert. Dazu hab ich ein eigenes Event angelegt BookEvent (und entsprechend eine Klasse BookListener, die alle implementieren müssen, die das Book-Objekt 'abhören' wollen).

 

[Mag1c]

Aha,

na das klingt doch relativ logisch und gut strukturiert

was du tun kannst/solltest:

- prüfen, daß nicht zu viele Events geschickt werden. Das passiert relativ schnell, daß man plotzlich eine Unmenge an sich überschneidenden oder gar doppelten Events verschickt.

- möglichst detaillierte Events verschicken (damit du z.B. TableModelEvents für einzelne Zellen generieren kannst). Aber ich vermute, das machst du bereits.

- Listener, die nicht sichtbar sind, abhängen.

- wenn du wirklich viele Bücher in der Tabelle hast und die für die Event-Erzeugung immer raussuchen mußt, könntest du im TableModel eine Map Buch -> Index verwalten.

Gruß
Mag1c

 

[Elephant]

Danke für Deine Antwort!

Die meisten Sachen, die Du erwähnt hast, mach ich schon, außer dem Map, dass hatte ich mir auch überlegt, aber das ganze an sich gefällt mir nicht besonders. Deswegen hab ich wegen den aufrufenden Objekten gefragt.

Weißt Du vielleicht wie man das besser strukturieren kann, damit das nicht am Ende ein völliges Durcheinander wird. Mir fällt einfach nichts logisches ein. Wenn man nur ein View hätte, wäre ja alles relativ einfach, aber bei mehreren Views komme ich immer ins Straucheln.

 

[Mag1c]

Hi,

na das klingt doch relativ logisch und gut strukturiert

das war ernst gemeint.

du könntest in das Interface BookListener eine Methode "boolean listenAtBookEvents()" aufnehmen und nur an die Listener das Event schicken, die dort true zurückliefern. Damit könntest du einzelne Views aus der Benachrichtigung ausschließen. Du könntest auf das Event-Schicken in einen Thread auslagern, mußt dann nur bei der GUI-Aktualisierung aufpassen wegen Thread <> AWTEventThread.

Gruß
Mag1c

 

[AlArenal]

Ich habe hier auch Anwendungen, in denen ein Model in mehreren Views verwendet wird. Dabei handelt es sich beiden Views um Trees, TreeTables und auch spezielle Views (zur Visualisierung von Graphen).

Im Grunde habe ich die "Event-Problematik" so gelöst, dass ich ein zentrales Model habe, welches meine Daten beherbergt. Alle anderen Models (TreeModel, TreeTableModel und mein Document für den GraphView) greifen lesend auf dieses Model zu und sind dort als Listener registriert. Schriebende Zugriffe auf Daten werden nur im ZentralModel gemacht und das feuert an seine Listener passende Events ab, die dann ggf. innerhalb der darüberliegenden Models umgestrickt werden.

Das Ganze funktioniert z.B. indem du das ZentralModel als public Singleton implementierst, so dass du von überall die Methoden zur Abfeuerung der Events losschicken kannst, oder aber du lässt die übrigen Model ihre Methoden nach unten weiterreichen, ohne selbst Events abzufeuern.

Also:
- ein zentrales Model für alle Daten
- nur das zentrale Model generiert Events
- alle übrigen Model setzen auf das zentrale Model auf, sind dort als Listener registriert, und formen von "unten" empfangene Events nötigenfalls um, um sie dann an die eigenen Listener weiterzureichen

Ist rein textlich doof zu beschreiben..

 

[Elephant]

Danke!!

Das mit der Methode listenAtBookEvents() ist echt eine gute Idee. Viel besser als immer das aufrufende Objekt mitzugeben.

Das mit den Threads muss ich mir erstmal durchdenken

@AlArenal
Ich habs auch so ähnlich gemacht, die Book-Objekte schicken die Events, die dann z.B. vom Bibliotheks-Objekt weitergereicht werden etc. Das mit dem Singleton etc. werde ich erstmal versuchen zu verstehen und schauen ob ich das so umsetzen kann.

 

[AlArenal]

Ich glaube so langsam blicke ich durch, was du gestrickt hast - oder zumindest meine ich das.

Ich halte es für etwas aufgebläht. Nehmen wir mal als Analogie ein einfaches Beispiel - nen Datei-Browser. Da haste nun den Verzeichnisbaum und die Dateien eingelesen und fleißig Datei-Instnazen in irgendeine Liste eingefügt. Und nun soll jede Datei eine Liste mit Listenern führen und die benachrichtigen? Hm...

Das wäre ja so, als hätte jeder Apfel Räder und nen Motor und würde bei Erreichen der Reife von selbst zum Kunden fahren und sich anbieten...

Meiner Meinung/meinem ästhetischen Empfinden nach gehören deine Bücher alle zusammen in ein Model, möglicherweise zusammen mit deinen Bibliotheken. Ich weiß ja nicht genau was du alles mit der Anwendung abdecken willst. Vielleicht können wir zweckdienlichere Tipps geben, wenn du kurz schilderst, was die Anwendung denn eigentlich machen soll?

 

[Elephant]

Ich finde es auch ziehmlich aufgebläht, aber wie gesagt fällt mir nicht so richtig eine bessere Umsetzung ein.

Also es gibt Bibliotheks-Objekte, die als Variablen z.B. den Namen etc. haben und außerdem eine ArrayList mit Book-Objekten.

Die Anwendung muss einmal alle Buch-Objekt einer Bibliothek in einer JTable darstellen. Dort können die Bücher bearbeitet werden. In einer anderen JTable wird nur ein einzelnes Buch-Objekt dargestellt, dort kann es auch bearbeitet werden.

Außerdem gibt es noch mehrere JTrees die z.B. die Bücher nach Kategorien sortiert anzeigen. In den JTrees kann man die Buch-Objekte selbst nicht bearbeiten nur löschen und hinzufügen.

Die JTables haben ein Model das vom AbstractTableModel abgeleitet ist. Dem AbstractTableModel liegt ein Bibliotheks-Objekt zugrunde. Wenn ich jetzt über die JTable einen Wert ändere. Ändere ich per set-Methode das entsprechende Buch-Objekt. Ich gehe dabei aber nicht erst über das Bibliotheks-Objekt (ich weiß nicht ob man das lieber machen sollte) sondern greife direkt auf die Buch-Objekte zu und ändere sie. Deshalb schickt das Buch-Objekt z.B. ein Event an das Bibliotheks-Objekt, das das Buch-Objekt enthält. Weil andere Views sich nicht bei den einzelnen Buch-Objekten angemeldet haben, sondern bei dem Bibliotheks-Objekt.


Bei der JTable für ein einzelnes Buch, ändere ich auch direkt das Buch-Objekt und schicke vom Buch-Objekt eine Nachricht an das Bibliotheks-Objekt, so dass sich z.B. die JTable mit allen Büchern der Bibliothek aktualisiert.

Hmm, ich hoffe das war ein bissel verständlich.

Danke für eure Hilfe.

 

[AlArenal]

Wie ich es jetzt ad hoc machen würde.

Ich bastel mir drei Klassen:
- Buch:
Enthält eine Liste 'kategorien', die man per addKategorie(Kategorie kat), ... ändern und abfragen kann.
Enthält eine Referenz 'bibliothek', denn ein Buch kann ja nur in einer Bibliothek stehen/zu ihr gehören.
- Bibliothek:
Enthält eine Liste 'buecher', die man ebenfalls ändern und abfragen kann.
- Kategorie:
Enthält eine Liste 'unterkategorien' und eine Referenz 'oberkategorie'.

Nun bastelst du dir ein zentrales Model, in dem du alle Bücher, Bibliotheken und Kategorien pflegst. Sie setzt auch die Beziehungen zwischen diesen, versetzt also ein Buch von einer Bibliothek in eine andere, ändert Zugehörigkeit zu einer Kategorie, etc. So hast du eine Klasse, die dafür zuständig ist, dass die Referenzen der Objekte untereinander stimmig bleiben.
In diesem Model kannst du nun z.B. ein TableModel für Bücher, eines für Bibliothekn und ein TreeModel für Kategotrien implementieren. Bei änderen an den Daten kannst du diese Models dann die passenden Events feruern lassen, die dein zentrales Model dann an die passenden Listener losschickt. So hätte dein zentrales Model z.B: diese drei Methoden:
- addBibliothekModelListener(TableModelListener l)
- addBuchModelListener(TableModelListener l)
- addKategorieListener(TreeModelListener l)

...

Mach dir da mal ganz in Ruhe mit Bleistift und Papier Gedanken über eine sinnige Struktur und die richtige Verteilung von Aufgaben und Verantwortungen in deinem Programm...

Möglichkeiten das umzusetzen, gibt es derer viele.

 

[Elephant]

Über die Struktur hab ich mir schon ewig Gedanken gemacht (auch mit Zettel und Papier etc.) und hab schon hin- und herimplementiert, aber so richtig gefallen hat mir nichts, es war alles viel zu umständlich :?


Darf ich nochmal nachhaken bei Deinem Vorschlag?
Du hast geschrieben:

In diesem Model kannst du nun z.B. ein TableModel für Bücher, eines für Bibliothekn und ein TreeModel für Kategotrien implementieren. Bei änderen an den Daten kannst du diese Models dann die passenden Events feruern lassen, die dein zentrales Model dann an die passenden Listener losschickt.

Die Frage ist, wie meinst Du das, dass man IN diesem Model ein z.B. TableModel für Bücher erstellt?

Also bis jetzt habe ich einfach ein BookTableModel dem ich ein Buch-Objekt als Referenz übergebe. Dieses BuchTableModel ist aber kein Teil des zentralen Models. Es meldet sich nur bei dem Buch-Objekt als Listener an, falls eine andere View es ändert und bei der Bibliothek des Objekts, falls das Objekt gelöscht wird.

Und wenn ich jetzt z.B. in der JTable für ein Buch einen Eintrag ändere, wie werden dann die anderen Views bei deinem Ansatz benachrichtigt? Und wo muss ich dieses TableModel als Listener anmelden, damit es benachrichtigt wird, wenn eine andere View das Buch-Objekt ändert.

Entschuldigung, dass ich das noch nicht so ganz verstanden hab. Es wäre echt nett, wenn du vielleicht noch ein paar Hinweise geben könntest.

 

[Mag1c]

Hi,

zeig doch mal eines deiner TableModels (z.B. von der Bibo, wo du alle Bücher siehst)

Gruß
Mag1c

 

[Elephant]

Also hier ist das BookTableModel (alles unwichtige, sortieren etc. hab ich mal rausgelassen).
Über den Zugriff auf die Variablen des Buchs sollte man sich nicht wundern. Ein Buch kann beliebig viele Variablen haben, deshalb kann man die nicht vorneweg festlegen. Deshalb liegen die Attribute in einer Hashtable wobei der key der Attributename ist und value der Attributwert.

public class BookTableModel extends AbstractTableModel {


    private ArrayList attributes;
    private ArrayList books;
    
    // brauch ich nur wegen Filterung und Sortierung
    private ArrayList allAttributes;
    private ArrayList allBooks; 


    public BookTableModel(Library library) { setLibray(library);  }


    private void setLibray(Library library) {

        if(this.library != null) { library.removeLibraryListener(this); }
        this.library = library;
        library.addLibraryListener(this);

        createAttributes();
        createBooks();

        fireTableStructureChanged();
    }

    private void createBooks() {
        allBooks = library.getBooks();
        books = (ArrayList) allBooks.clone();
    }

    
    private void createAttributes() {
        allAttributes = library.getAttributes();
        attributes = (ArrayList) allAttributes.clone();
    }


    public int getRowCount() {
        return (books == null) ? 0 : books.size();
    }

    public int getColumnCount() {
        return (attributes == null) ? 0 : attributes.size();
    }

    public Object getValueAt(int row, int column) {
        return ((Book)books.get(row)).getAttribute((String)attributes.get(column));
    }

    public String getColumnName(int column) {
        return (String) attributes.get(column);
    }

    public boolean isCellEditable(int row, int column) {
        return true;
    }

    public void setValueAt(Object value, int row, int column) {
        try { ((Book)books.get(row)).setAttribute((String)attributes.get(column), (String) value); }
        catch(BookException e) { /* do nothing */ }
    }


    public void libraryChanged(LibraryEvent e) {
        if(e.getType() == LibraryEvent.BOOK_CHANGED) {
            // update table
        }
    }
}

Naja, ich weiß nicht ob ihr soviel damit anfangen könnt.

 

[AlArenal]

Was ich mir da denke ich ein wenig komplex, um das hier rein mit Text zu erklären. Und ich habe auch nicht ewig Zeit um hier schon alles vorzubereiten und zu coden

Ich habs zwar nie überarbeitet und es mag etwas abstrakt sein, aber schau mal rein, vielleicht bringt es dich auf Ideen:

http://wiki.alexander-langer.de/index.php/JTree:_Gefilterte_Anzeige

 

[Mag1c]

Hi,

das libraryChanged wäre jetzt noch interessant gewesen.

du könntest festlegen, daß auch in der Bibliothek die Bücher in einer Reihenfolge verwaltet werden (hast du ja implizit durch die ArrayList). Dann würde die Bibo auch einen Buch-Index haben, den du mit in die Events einbauen könntest.

Muß das mit dem ArrayList#clone wirklich sein ? Du hast doch jederzeit über die Library Zugriff auf die Originalliste.

Gruß
Mag1c

 

[Elephant]

Also das clone mache ich, da die Bücher in der Bibliothek in einer Hashtable liegen, da sie eine eindeutige ID, die vorgegeben ist, haben. Und da ich die ArrayListe des Models sortiere oder filtere, bringt es mir auch nicht so viel, wenn ich einen Index aus der Library hätte. Da müsste ich auch erst wieder schauen, wo das original Buch-Objekt liegt.


@AlArenal
Ich hab mir schon fast gedacht, dass man das nicht so einfach aufschreiben kann Die Seite werde ich auf alle Fälle mal durchlesen, ich glaube, ich war da sogar schon mal drauf, als ich nach einer Möglichkeit zum Filtern gesucht hab.

 

[AlArenal]

Ist im Grunde recht einfach, nur vielleicht scheiße erklärt

 

[Elephant]

Ich finds eigentlich richtig gut erklärt und vor allem übersichtlich. (und das sag ich jetzt nicht nur so)

Vielleicht kannst Du mir doch noch eine Frage beantworten, nur wenns eine schnelle Antwort gibt.

Du schreibst ja unten selber:

Erweiterst du dein Model und denFilter z.B: um eine Methode remove(Object obj), dann lasse den Filter einfach nur die MEthode des delegates (also des Models) aufrufen. Das Model muss sich dann ums Löschen und das Auslösen des Events kümmern. Der Evetn selbst krabbelt dann die ganze Kette nach oben, bis er am JTree ankommt.

Das ist bei mir auch so und da seh ich eben die "Performance-Einbußen". Also ich erklärs mal am JTable statt am JTree. Wenn ich jetzt im Filter Model die remove Methode hab, rufe ich die remove Methode des delegates auf. Schicke dort das Event los, das dann 'hochkrabbelt' wieder zurück zum FilterModel.

D.h. aber beim FilterModel könnte ich noch z.B. das Event TableModelEvent(source, 3, 60) (wenn Zeile 3 bis 60 geändert wurden) schicken und die JTable weiß gleich was sie tun soll. Wenn ich jetzt aber auf die Events reagiere, die vom delegate kommen, dann muss ich z.B. erstmal raussuchen, welche Zeile das denn nun jeweils ist, die geändert wurde, weil ja z.B. die grad gar nicht angezeigt wird oder bei einem Sortierten-Model statt einem Filter ganz woanders steht. Das heißt es kostet Zeit, denk ich mir mal so.

Macht man es trotzdem so?

 

[Mag1c]

Hi,

hast du mal geguckt, wieviel Zeit du beim filtern/sortieren im TableModel verlierst ?

Gruß
Mag1c

 

[AlArenal]

Klar gibt es eine "performance penalty" durch zusätzliche Abstraktionesebenen, Filterung von Daten, Untersuchung von Events...

Stellt sich aber die Frage, ob dies merkliche Auswirkung auf die Anwendung hat (Ist es spürbar?). Auf der Seite beziehe ich mich ja zunächst einmal auf TreeModels und da habe ich Erfahrung mit einem zentralen Model, über das mehrere andere Models zur Filterung gestülpt sind und auf denen teils JTrees sitzen, an denen teils aber auch Adapter sitzen um die Daten für einen View zur Visualisierung eines Graphen aufzubereiten. Im Fall dieser TreeModels funktioniert das ohne die geringsten spürbaren Performance-Verluste.
Ein solcher Tree zeigt ja in der Regel nur eine kleine Menge von Nodes an. Das Auslesen und filtern von Daten ist für solch kleine Datenmengen von vernachlässigbarem Aufwand.

Bei einem TableModel mit vielen Daten mag es etwas anders aussehen, wenn die Daten noch dynamisch sortierbar sind. Hier muss man beim Renderer drauf achten, nicht für jeden Aufruf des Renderers die ganzen Daten neu umzustricken, wenn sich dies in der Praxis als Hemmschuh herausstellt.
Das kann man machen, indem man z.B. beim Andocken des FilterTableModels and das DatenTableModel und bei dem Ändern des Filters / der Sortierung / sonstwas.. die Daten nur einmal aus dem DatenTableModel liest und im FilterTableModel vorhält (z.B. in einer List). Zugriffe des Views (also JTable)/des Renderers auf das FilterTableModel erfolgen dann auf die bereits zusammengesuchten und vorsortierten Daten.
Bei ankommenden Events muss man dann u.U. die vorgekauten Daten auch nochmal neu einlesen oder was rauslöschen, ...

Diese Optimierung ist m.E. aber etwas, was man auch nachträglich einbauen kann, sollte es sich als nötig erweisen, ohne dass der View oder sonstwas ebenfalls umgestrickt werden müsste.

 

[Elephant]

Danke für Deine Hilfe!

 

[AlArenal]

BTW bin ich gerade nebenher dabei das Filtern und Sortieren in TreeModels und das Ableiten von Subtrees in eine eigene API zu packen, um das auch für mich ein für allemal festgezogen zu haben (da ichs doch öfter mal brauche).

Im Kern steht dann sowas:

public interface TreeFilterModel extends TreeModel {
	public TreeFilter getTreeFilter();
	public void setTreeFilter(TreeFilter filter);
	public TreeFilterModel getSubTree(TreePath rootPath);
}

Uneins bin ich mir noch, ob ich die Sortierung in TreeFilter, oder in TreeFilterModel unterbringe. Der eigentlich Aufwand wird es dann die Referenzimplementierungen zu machen und ne vernünftige Demo zu schreiben.