aschael
I'm new here

Geöffnetes Eingabeformular per API ansprechen

Jump to solution

Hallo,

bei einem unserer Projekte besteht die Anforderung Datensätze direkt aus dem Eingabeformular Freigeben zu können. Das beinhaltet, dass Änderungen die zwischen dem Öffnen und der Freigabeaktion vorgenommen wurden vorher gespeichert werden. Dafür habe ich einen entsprechenden FS_BUTTON angelegt, der die Formularfelder des Datensatzes als Params übergeben kriegt.

Es funktioniert auch soweit alles. Allerdings ist nach dem Freigabeworkflow weiterhin das Eingabeformular geöffnet und  der Speichern-Button aktiv, weil das Eingabeformular nicht weiß, dass sein Status mit dem gespeicherten Status nun übereinstimmt. Wenn der Benutzer dann auf speichern drückt wird eine neue, nicht freigegebene, Version gespeichert und für den Nutzer sieht es so aus als wenn der Datensatz gar nicht freigegeben wurde. 

Die Frage ist nun also:

Gibt es irgendeine Möglichkeit auf das geöffnete Formular im ContentCreator (per WEB_API oder Java-API) zuzugreifen und entweder den Status zu refreshen um den Speichern-Button auszugrauen, oder das Formular einfach  zu schließen?

Ich konnte in der Doku dazu nichts finden aber vielleicht (hoffentlich) hab ich ja uch einfach etwas übersehen.

VG

Anja Schälicke

0 Kudos
1 Solution

Accepted Solutions

Hallo Anja,

ich denke das sollte sich über einen Clientservice lösen lassen. Das wären zwar ein paar kleine Umwege, aber sollte schnell gemacht sein. Ohne Garantie 😉

Idee: Über ein PermanentPlugin einen einfachen Clientservice registrieren, der drei Methoden hat: rememberElement(..), clear() und release().

Der Button im Formular würde dann das Speichern und freigeben nicht selbst machen, sondern das Element (oder auch nur dessen fs_id oder GID, also irgendwas über das man den Datensatz später identifizieren kann) in den ClientService legen. Der Button ist hier nötig, weil du nur über dessen Kontext das Element hast (im Gegensatz zu einem ValueService o.ä.) und da es ja eine Übersichts-Seite ist, kommst du auch z.B. über den WebeditUIAgent.getPreviewElement nicht an den Datensatz ran. Also per Button onClick -> Executable aufrufen, das sich deinen ClientService holt und dort die Infos rein schiebt aber sonst erstmal weiter nichts macht.

Dann bräuchtest Du noch einen Mechanismus, der nach dem Schließen des Formulars die release-Methode des clientservice triggert. Die würde, falls kein gemerktes Element da ist einfach nichts tun. Ansonsten die Freigabe durchführen und dann (wichtig!) das gemerkte Element (bzw. dessen Infos) über die clear()-Methode ebenfalls im ClientService „vergessen“.

So müsstest Du eigentlich auf der Vorschauseite (einfach im Template) immer nur z.B. per WE_API.common.execute(...) das release() des Clientservice aufrufen.

Evtl. müsste man dann noch ein bisschen tricksen (vielleicht über einen ValueService mit einer Rule when="onSave" o.ä.) um den Fall abzufangen dass zwar der Freigegeben-Button geklickt, das Formular dann aber per „Abbrechen“ geschlossen wird.

Viele Grüße

Michael

View solution in original post

0 Kudos
7 Replies
aschael
I'm new here

Hallo,

ich versuch mich mal nochmal in die Aufmerksamkeit zu schummeln. Hat vielleicht jemand eine Idee dazu?

VG

Anja Schälicke

0 Kudos

Hallo Anja,

kommt drauf an, wie du in dem Moment denn die Freigabe des aktuellen Datensatz überhaupt machst.

Im SiteArchitect dürftest du bei einem Button gar nicht wissen, wo du dich befindest, es sei denn du nutzt den UIStoreAgent, der nicht Teil der API ist.

Wenn du ihn nutzt, dann würde ich einfach das Lock entziehen. Dies muss man aber halt auf dem GuiStoreElement machen und nicht auf dem tatsächlichen StoreElement/IDProvider:

agent = context.requireSpecialist(UIStoreAgent.TYPE);

agent.getActiveUiElement().removeLock();

Viele Grüße

Felix

0 Kudos

Hi Felix,

vielen Dank für den Vorschlag!

Ich brauche das für die Formulare im ContentCreator. Das Element und die zu speichernden FormFields bekomme ich direkt aus dem Context und mit dem Lock habe ich eigentlich auch kein Problem an der Stelle. Ich speichere also erfolgreich direkt auf dem Element die Eingaben (im SiteArchitect werden mir danach die richtigen Daten angezeigt) und der Freigabe-Workflow läuft auch wie er soll. Nur das immernoch offene Formular verhält sich nicht richtig.

Den UIStoreAgent würde ich nur sehr ungern nutzen, wenn er nicht Teil der API ist.

Vermutlich werde ich wohl einen kompletten PageReload durchführen müssen nach der Speichern-Freigabe-Kombo. Das gefällt mir zwar nicht wirklich, birgt aber glaube ich weniger Fehlerpotenzial für die Nutzer.

Noch bin ich aber für schönere Vorschläge offen Smiley Happy

VG

Anja

0 Kudos

Hallo Anja,

geht es hier wirklich exakt um ein "Speichern aus dem Formular heraus per Button" oder generell um eine einfache Möglichkeit, im Formular "irgendwie zu sagen", dass nach dem Speichern direkt eine Freigabe erfolgen soll? "Aus dem Formular heraus per Button" halte ich persönlich rein technisch für nicht so gut, alleine schon wegen der "Synchronisierungs"-Problematik.

Wäre ggf. auch eine Variante mit einem Toggle (oder etwas ähnliches) "nach dem Speichern freigeben" im Formular OK? Nicht dass ich dazu schon eine defnitiv funktionierende Lösung im Kopf hätte, aber dann könnte man auch mal in eine etwas andere Richtung denken 😉

Ich gehe davon aus, dass ihr zum Öffnen der Datensatz-Formulare die ganz normale editorId()-Funktion in einer Tabellenvorlage nutzt, richtig?

Viele Grüße

Michael

0 Kudos

Hi Michael,

im Grunde möchte ich dem Formular sagen, dass nach dem Speichern direkt eine Freigabe passieren soll, oder andersrum so wie ich es jetzt gelöst habe, dass vor dem Freigeben gespeichert werden soll. Hintergrund ist, dass wir Übersichtsseiten haben für viele Datensätze die über ein JS-Plugin sortiert als Listeneinträge ausgegeben werden. Wenn ein Redakteur einen Eintrag aus der Mitte dieser Liste bearbeitet, wird die Vorschau neu geladen (das muss auch so sein) und der Redakteur muss den Datensatz erneut raussuchen um die Freigabe durchzuführen.

Im Grunde wäre so ein Toggle also auch ok, aber dann müsste ich mich ja irgendwie an den Speicherprozess ranhängen. Ich würde mich dann ich eher damit zufriedengeben, dass halt die ganze Seite neu geladen werden müsste glaube ich.

Und richtig wir verwenden ganz normal editorId().

Ich würde also einsehen, dass die Antwort auf meine Eingangsfrage "nein" ist und ich das $irgendwie umgehen muss.

Vielen Dank für die Anregungen

Anja

0 Kudos

Hallo Anja,

ich denke das sollte sich über einen Clientservice lösen lassen. Das wären zwar ein paar kleine Umwege, aber sollte schnell gemacht sein. Ohne Garantie 😉

Idee: Über ein PermanentPlugin einen einfachen Clientservice registrieren, der drei Methoden hat: rememberElement(..), clear() und release().

Der Button im Formular würde dann das Speichern und freigeben nicht selbst machen, sondern das Element (oder auch nur dessen fs_id oder GID, also irgendwas über das man den Datensatz später identifizieren kann) in den ClientService legen. Der Button ist hier nötig, weil du nur über dessen Kontext das Element hast (im Gegensatz zu einem ValueService o.ä.) und da es ja eine Übersichts-Seite ist, kommst du auch z.B. über den WebeditUIAgent.getPreviewElement nicht an den Datensatz ran. Also per Button onClick -> Executable aufrufen, das sich deinen ClientService holt und dort die Infos rein schiebt aber sonst erstmal weiter nichts macht.

Dann bräuchtest Du noch einen Mechanismus, der nach dem Schließen des Formulars die release-Methode des clientservice triggert. Die würde, falls kein gemerktes Element da ist einfach nichts tun. Ansonsten die Freigabe durchführen und dann (wichtig!) das gemerkte Element (bzw. dessen Infos) über die clear()-Methode ebenfalls im ClientService „vergessen“.

So müsstest Du eigentlich auf der Vorschauseite (einfach im Template) immer nur z.B. per WE_API.common.execute(...) das release() des Clientservice aufrufen.

Evtl. müsste man dann noch ein bisschen tricksen (vielleicht über einen ValueService mit einer Rule when="onSave" o.ä.) um den Fall abzufangen dass zwar der Freigegeben-Button geklickt, das Formular dann aber per „Abbrechen“ geschlossen wird.

Viele Grüße

Michael

0 Kudos

Hi Michael,

danke! Wir werden das hier intern nochmal besprechen, ob und wann wir das so umsetzen. Ich denke aber das ist die am wenigsten unsaubere Lösung, deshalb markier ich sie jetzt schonmal ungetestet als korrekte Antwort. Falls es noch irgendwelche Auffälligkeiten gibt schrieb ich sie dann noch nachträglich hier in das Ticket.

VG

Anja

0 Kudos