Feature Discussions

[Hendrik]

Ist-Zustand:

Über einen StoreListener ist es derzeit möglich auf Änderungen an Stores programmatisch zu reagieren (Element wurde erstellt, gelöscht, verschoben etc.). Dies ist über ein Listener-Mechanismus realisiert, Listener-Implementierungen die an Stores registriert sind werden bei Änderungen mittels spezieller Methode informiert. Diese Methoden bekommen als Übergabeparameter das StoreElement, an welchem die Änderung in einem Store aufgetreten ist, übergeben. Details können der Access-API  entnommern werden (http://www.e-spirit.com/odfs42/access/de/espirit/firstspirit/access/store/StoreListener.html).

Idee:

Leider ist die derzeit implementierte Lösung meiner Meinung nach unzureichend, da bei Änderungen zu wenig Metainformationen über die API abgegriffen werden können. Wünschenswert wäre ein richtiger Event Mechanismus, so wie er auch von Swing bekannt ist. Beispielsweise könnte ein StoreChangedEvent folgende Informationen an einen StoreEventListener übertragen:

• wann wurde das Event ausgelöst (Metainformation, fehlt derzeit)
• von welchem Benutzer wurde das Event ausgelöst (Metainformation, fehlt derzeit)
• in welcher Session (für den Fall das ein Benutzer meherer Session offen hat) wurde das Event ausgelöst (Metainformation, fehlt derzeit)
• der Typ des Events (AddedToScope, RemovedFromScope, Moved, Deleted, Changed etc)

Darüber hinaus wäre es gute wenn Events in regelmäßigen Abständen zu den Clients übertragen werden, derzeit geschieht dies nur nach manuellem Refresh eines Stores in der Baumansicht.

z.B. Client A verschiebt ein Element, Client B bekommt die Verschiebe-Aktion nur dann als Event wenn manuell der Baum (in dessen Teil das verschobene Element besteht / bestand) aktualisiert wird. Schön wäre es wenn der Client solche Events im Hintergrund Empfangen würde und so die Aktualisierung im automatisch ablaufen würde, die Baumansicht somit fortlaufen in kleinen Abständen aktualisiert wird.

Beispiel für einen Anwendungsfall:

Bei Verschiebe-Aktionen im Strukturbereich sollen Prüfungen erfolgen, die eine konsistente Strukur im Strukturbereich sicherstellen (z.B. soll die letzte Seitenreferenz / Knoten eines Startordners A, der bereits einmal freigegeben wurde, nicht aus dem Order A herausgeschoben werden können, da sonst die Gefahr besteht das dieser dann leere Ordner beim Generieren aus der Navigation verschwindet). Eine solche Prüfung soll in dem Redaktionsclient erfolgen in dem die Verschiebe-Aktion durchgeführt wurde. Mit den derzeitigen Mittel lässt sich ein solches Szenario nur unzureichen implementieren, es ist zwar möglich auf die Verschiebung zu reagieren, aber da die besagten Metainformationen nicht zur Verfügung stehen sind nur eingeschränkte Aktionen möglich. Derzeit lassen sich die fehlenden Metainformationen nur umständlich und auf unsicheren Wegen, bspw. durch zeitintensives prüfen von Revisionen, ermitteln. Einige Metainformationen (z.B. die Benutzersession) sind nicht ermittelbar (soweit mir bekannt).

[alexanderan]

Genau diese Funktionaliät benötigen wir. Sehr guter Vorschlag

[Peter_Jodeleit]

Der Typ des Events ergibt sich aus der Callback-Methode ("elementMoved", "elementChanged", etc.).

Wann und Wer ergibt sich aus StoreElement.getRevision().

Darüber hinaus wäre es gute wenn Events in regelmäßigen Abständen zu den Clients übertragen werden, derzeit geschieht dies nur nach manuellem Refresh eines Stores in der Baumansicht.
                   

Dafür ist dies API nicht gedacht. Für den beschriebenen Anwendungsfall würde ich auch keinen Vorteil sehen.

[Hendrik]

Hallo Herr Jodeleit,

wie von mir beschrieben ist es durchaus möglich einige Metainformationen durch aufwendiges Prüfen der Revisionen zu erhalten. Es reicht leider nicht aus nur die an dem StoreElement über getRevision() zu beziehende Revision zu untersuchen, da bspw. zwischen einer Verschiebe-Aktion und einer Änderung eines Elements mehrere Revisionen entstehen. Das jeweilige Element des Events, welches in meinen Tests an die dem Event ensprechende Listener-Methode übergeben wurde, war nicht immer in der Revision aus welcher das Event resultiert ist.

Somit muss m.E. die Revisionshistorie untersucht werden was wiederum Zeit in Anspruch nimmt die im Client knapp ist da, sofern keine Implementierung mittels SwingWorker o.Ä. vorgenommen wird, die Verarbeitung im Event Dispatching Thread (EDT) von statten geht und somit negativen Einfluß auf die "gefühlte" Performance des Client haben kann.

Die Benutzersession des Event auslösenden Benutzers ist m.W. derzeit nicht ermittelbar, wäre aber für meinen aufgeführten Anwendungsfall durchaus relevant wenn ein Power-User mehrer Clients offen hat ohne jetzt ins Detail gehen zu wollen.

Ich meine das wenn schon ein solcher Listener-Mechanismus eingesetzt wird, ein solcher auch die entsprechenden Metainformationen wie ein richtiger Event Mechanimus mitbringen sollte so dass die Informationen nicht erst umständlich ermittelt werden müssen.

[Peter_Jodeleit]

Wie gesagt, dafür ist die API nicht gedacht, unterstützt diesen Anwendungsfall daher auch nicht. Wenn ich den Anwendungsfall richtig verstehe, soll bei bestimmten Aktionen eine Art "Veto" eingelegt werden. Da macht es in meinen Augen keinen Sinn, Events aus anderen Sessions zu beachten (auch wenn sie vom gleichen Benutzer sind). Wie Sie richtig beobachtet haben, kommen aber auch Events  für Änderungen, die von anderen Benutzern vorgenommen werden, sobald das entsprechende Element lokal aktualisiert wird.

[EDIT]

Was ich damit ausdrücken will: Dafür müsste eine neue API geschaffen werden, diese würde dann nur Events für "meine Änderungen" feuern und eine Veto-Möglichkeit erlauben.

[Hendrik]

Richtig, für den beschriebenen Anwendungsfall soll bei bestimmten Aktionen des Benutzers im Redaktionsclient, die über den Listener getriggert werden, ein Veto eingelegt bzw. eine bestimmte Aktion durchgeführt werden. Im Grunde würde es reichen die API so zu erweitern, dass bei der Registrierung des Store Listener ein "Scope" übergeben werden könnte der angibt, ob nur lokale, nur serverweite oder alle Store Events an den Listener weitergereicht werden sollen.

Für welche Anwendungsfälle die API gedacht ist (und wie sie im Detail tickt) geht leider aus keiner Dokumentation hervor.

[kohlbrecher]

Hallo Hendrik,

mit der FirstSpirit Version 2021-05 wurde die API um einige Event-Klassen erweitert. Mit diesen sollten die gewünschten Informationen erreichbar sein.

Weitere Details finden sich in den Releasenotes im Kapitel 5.1.

Viele Grüße

Jan