Questions & Answers

[novomind]

Hallo,

der Titel ist vermutlich etwas verwirrend, also erkläre ich einmal kurz worum es geht:

Wir haben folgende fiktive Struktur:

"BeispielPage"

    -top

    -content_left

    -content_right

    -bottom

       ->Bild

       ->Text

       ->Bild

Wir haben ein Modul (SwingGadget) gebaut, mit dem es möglich ist die Sections "Bild", "Text" und "Bild" beliebig innerhalb des Inhaltsbereichs zu platzieren. (Im ausgespielten Inhalt)

Die drei Sections beeinflussen sich während der Platzierung gegenseitig in ihren Positionen und sollen Überschneidungen als Konflikte direkt anzeigen. Wir brauchen also Zugriff auf das lokale Model der jeweils anderen aktiven Sections des gleichen Inhaltsbereiches.

Und da ist das Problem. Wir sehen aktuell keine Möglichkeit, einen zentralen SectionManager zu bauen, der alle aktiven Sections bei einer Neupositionierung verwalten kann, da eine Section keinen Zugriff auf Gadgets anderer Sections hat.

Lösungsmöglichkeit 1:

Wir brauchen Zugriff auf die Gadgets anderer Sections.

Lösungsmöglichkeit 2:

Wir bauen ein zentrales, lokales Model für das Modul und hängen dieses an den Knoten "Inhaltsbereich" (bottom, top, etc).

Beide Lösungsvarianten haben wir eingehend untersucht und keine Lösung gefunden. Haben wir etwas übersehen? Kann man aus einem SwingGadget heraus auf SwingGadgets anderer Sections irgendwie zugreifen? Wenn nicht, kann ich mein Section-übergreifendes Model an einen Parent einer Section hängen?

Derzeit arbeiten wir mit dem unschönen Workaround eines statischen Models, in dem wir eine static Map<Section ID, Model> verwalten, was mit zunehmender Komplexität an Schönheit und Sinn verliert, da hier auch Models von anderen Pages gespeichert werden. Das ist kein guter Stil und widerstrebt uns ziemlich

Wir sind für jeden Tipp dankbar,

viele Grüße aus Hamburg!

[StefanSchulz]

Hallo,

eventuell lohnt sich ein Blick auf die folgende Operation, die über den OperationAgent erreichbar ist:

http://www.e-spirit.com/odfs50/dev/index.html?de/espirit/firstspirit/ui/operations/OpenElementDataFo...

Mit dieser Operation erhält man einen Remote-Zugriff auf die (Live-)Formulare von Elementen. Allerdings werden diese dann auch angezeigt. Bin mir also nicht sicher, ob dieser Weg hilft.

Gruß

Stefan

[novomind]

Hallo Stefan,

danke für die Antwort. So ähnlich wurde es früher auch gehandhabt, in dem einfach das FormField überschrieben wurde. Dies scheint in FS jedoch auch Listener auszulösen, denn der ValueEngineer beginnt unmittelbar danach read() bzw. write() auszulösen und saved uns das "dirty" Objekt weg. Dies haben wir mittlerweile durch Implementierung eines ChangeManagers in den Griff bekommen, jedoch möchten wir von dieser Vorgehensweise Abstand nehmen.

Wir müssten hier nämlich weiterhin ständig zwei verschiedene Objekte pflegen (das lokal gecachte, schwebende Objekt und das persistierte Objekt) und gegenseitig synchronisieren, was in der Vergangenheit zu schweren Seiteneffekten geführt hat.

Trotzdem danke für den Tipp.

[StefanSchulz]

Was meinst du mit "FormField überschreiben" und "so ähnlich"?

Obige Operation führt zu einem Sprung zu dem übergebenen Element und liefert ein Zugriffsobjekt auf das dortige Formular. Ich bin mir nicht sicher, an welchere Stelle dies eine Schreiboperation auslösen sollte.

Über welche FS-Version reden wir?

[novomind]

Es wurde früher folgendermaßen realisiert:

FormData formData = currentSection.getFormData();
FormField<OurPersistedModel> formField = (FormField<OurPersistedModel>) formData.get(detectLanguageToUse(), getGomName());
formField.set(currentModel);

Dies führte aber dazu, den ValueEngineer zu triggern. FS hat sich dann unerlaubterweise unser Model geholt, das zu dem Zeitpunkt überhaupt nicht bereit dazu ist.

Was bewirkt FormField.set genau? Welchen Lebenszyklus hat ein Objekt, das so auf das FormField gesetzt wird?

Server-Version: 5.1.106.61855 -

[StefanSchulz]

Ok, mit dem Code habt ihr natürlich direkt auf den Daten des Absatzelements gearbeitet. Dann ist FormData eine Kapsel, die direkt auf dem Datenobjekt arbeitet und ein set() ändert dieses (schreibt somit auf den ValueEngineer durch). Zudem besteht keine Verbindung zwischen dem Datenobjekt des Elements und dem Formular, d. h., Änderungen im Objekt werden nicht im Formular sichtbar und beim Speichern werden diese Änderungen potentiell von den Formulardaten überschrieben.

Das RemoteFormField über die Operation arbeitet auf dem sichtbaren Formular und die Felder darin und nicht auf den Daten. Wird hier ein set() ausgelöst, und das Formular ist zum Bearbeiten gesperrt, wird die Eingabekomponente gesetzt. Der Wert wird aber erst mit dem Speichern des Formulars zurückgeschrieben.

[novomind]

Hallo Stefan,

danke für den Tipp, wir schauen uns das mal an.

Viele Grüße!