Search the FirstSpirit Knowledge Base
Hallo,
kurze Frage: Ist es aus Scripten heraus möglich, auf das Objektmodell des Java-Clients zuzugreifen? Anwendungen:
Danke & Grüße,
Arndt
Hallo Arndt,
wie versprochen, habe ich mich nochmal mit dem zweiten Punkt beschäftigt.
Es wurde intern noch der Ansatz vorgeschlagen, sich den umbenannten Absatz per Skript erneut zu holen und ihn dadurch zu aktualisieren. Dieser Ansatz zeigt bei mir aber dieselbe Wirkung, wie das bisherige Skript: Ohne eine manuelle Aktualisierung des Elements bzw. des Baums werden die Anzeigenamen des Absatzes nicht aktualisiert.
Wie mir intern auf eine weitere Nachfrage bestätigt wurde, darf bzw. kann dein Skript tatsächlich nicht dasselbe machen, wie der F9-Dialog, weil die API-Schnittstelle fehlt. Es müsste somit wirklich ein Feature Request gestellt werden.
Summa Summarum lässt sich die Situation also wie folgt zusammenfassen:
Das 1. Anliegen
Setzen aller Sprachen (aus den verschieden sprachlichen Feldern) bei nur einem Klick auf den Button gleichzeitig (egal auf welcher Sprache),
kann über das folgende Skript realisiert werden. Die Voraussetzung dafür ist jedoch,dass der Absatz nach dem Befüllen der Felder und vor dem Klicken des Buttons einmal gespeichert wird.
Skript:
//!BeanShell
import de.espirit.firstspirit.common.gui.*;
languages = element.getProject().getLanguages();
for(lang:languages){
langinfo = element.getLanguageInfo(lang);
formField = element.getFormData().get(lang, headline.getName());
langinfo.setDisplayName(formField.get());
}
Zum 2. Anliegen
sofortige Aktualisierung des Namens im Baum beim Button-Klick
siehe oben.
Alternativ wurde noch den Ansatz genannt, über den Button per Skript einen Dialog zu öffnen, der die Eingabefelder für die entsprechenden Sprachen enthält, deren Werte dann durch das Skript weiter verarbeitet und für die Anzeigenamen gesetzt werden. Ob dieses Vorgehen durch das Schließen des Dialogs eine Aktualisierung des Knotens im Baum und damit auch eine Aktualisierung der umbenannten Anzeigenamen hervorrufen würde, kann ich allerdings nicht sagen. Ich habe diesen Ansatz nicht getestet.
Abschließend möchte ich mich noch einmal für die von mir gestiftete Verwirrung entschuldigen. Dass in Schritt 4 der Baum durch das Schließen des F9-Dialogs aktualisiert wird, hatte ich tatsächlich übersehen, obwohl ich es ja noch selbst beschrieben hatte. Da war ich selbst zu sehr auf meine eigene Erklärung fixiert.
Lieben Gruß
Michaela
Hallo Arndt,
ist dieses Posting noch aktuell oder haben sich die Fragen inzwischen bereits geklärt?
Zur ersten Frage:
Der Refresh eines Baumes wird immer dann automatisch durchgeführt, wenn ein Element verändert wurde. Ein skriptgesteuerter Refresh sollte somit eigentlich nicht notwendig sein. Wie sieht denn der genaue Anwendungsfall aus, für den ein solcher Refresh gewünscht wäre?
Zur zweiten Frage:
Über einen FS_Button lassen sich Skripte starten, über die auch noch nocht nicht gespeicherte Werte auslesen können.
LG Michaela
Hallo Michaela,
ja, ist noch aktuell - danke, dass Du Dich erbarmst . Gleich ein Hinweis: Alles noch 4.2, aktuellste Version.
Der Post bezieht sich auf die Feature-Diskussion https://community.e-spirit.com/message/11727#1172. Mein Script, welches in der Maske per Button ausgelöst wird, ändert die Anzeigenamen einer Seite, Selbst wenn die vom Script gespeichert wird, wird der Knoten im Baum nicht mit dem neuen Namen aktualisiert - erst, wenn man im Baum einen Wechsel des Knotens per Hand macht (Mausklick). Kann ich den Refresh der Darstellung per Script anschieben?
Grüße & Danke,
Arndt
Hallo Arndt,
zum Punkt:
In dem von Dir verlinkten Posting liest es sich so, als würde der Zugriff auf die Anzeigenamen der anderen Sprachen fehlen. Dafür würde ich (ungetestet) wie folgt vorgehen:
languages = context.getProject().getLanguages();
for(lang : languages){
languageInfo = element.getLanguageInfo(lang);
languageInfo.setDisplayName("xyz");
}
Da Du in deiner letzten Antwort auf diesen Punkt nicht mehr eingegangen bist, scheint er jedoch bereits erledigt zu sein?
zum Punkt:
Ich habe den Fall bei mir lokal in einem Mithras-Projekt nachgestellt und ausprobiert. Während der Ausführung des Skripts befindet sich die Seite, deren Anzeigename geändert wird, im Bearbeitungsmodus. Alle Änderungen werden erst durch ein Speichern bzw. durch ein Verlassen des Bearbeitungsmodus (inkl. Speicherung) übernommen und persistiert. Daher wird auch der geänderte Anzeigename erst durch die entsprechende Handlung angezeigt/aktualisiert.
Andernfalls würde der Anzeigename einen nicht persistierten Wert annehmen. Würden die vorgenommen und noch nicht gespeicherten Änderungen anschließend verworfen (über STRG+Shift+E), hätte der Anzeigename eventuell gar keinen Wert mehr, da der ursprüngliche Wert durch den inzwischen verworfenen Wert überschrieben wurde und somit ebenfalls nicht mehr existiert. Dies ist nicht wünschenswert und daher auch nicht möglich.
Der Client verhält sich somit erwartungskonform.
Hallo Michaela,
witzigerweise ist es bei den beiden Aspekten nun genau anders herum, als ich dachte. Hier mal die aktuelle Situation
1. Formular mit Button-Aktion und Textarea
<CMS_INPUT_TEXTAREA
name="st_textarea_1"
convertEntities="quote"
hFill="yes"
maxInputLength="500"
noBreak="no"
useLanguages="yes">
<LANGINFOS>
<LANGINFO lang="*" label="Headline" description="Enter a headline"/>
<LANGINFO lang="DE" label="Überschrift" description="Überschrift ausfüllen"/>
</LANGINFOS>
</CMS_INPUT_TEXTAREA>
<FS_BUTTON
name="st_button_1"
allowEmpty="yes"
hFill="no"
icon="info"
noBreak="no"
onClick="script:change_section_name"
style="button"
useLanguages="no">
<LANGINFOS>
<LANGINFO lang="*" label="Rename section after headline" description="Make renaming easier"/>
</LANGINFOS>
<PARAMS>
<PARAM name="headline">#field.st_textarea_1</PARAM>
<PARAM name="thisform">#field</PARAM>
</PARAMS>
</FS_BUTTON>
und folgendes Click-Script auf dem Button:
//!BeanShell
import de.espirit.firstspirit.common.gui.*;
langinfo = element.getLanguageInfo(language);
newname = headline.get().toString().replaceAll("\n"," ");
langinfo.setDisplayName(newname);
CMSDialog.showInfoDialog("Renamed language " + language.toString() + " to \"" + newname + "\"");
element.refresh();
Das macht genau das, was es soll: In der aktuellen Sprach den Inhalt der Textarea als Display-Text des Absatzes einfügen. Wenn man nicht speichert, ist das dann wieder weg. Aber so soll es sein.
Witzigerweise geht der Refresh jetzt - das war zu dem Zeitpunkt, als ich den Post schrieb, noch nicht so. Das hab ich hier noch als Mail dokumentiert. Allerdings sind schon wieder 1-2 Updates rausgekommen (wir reden ja noch von 4.2), wo das wahrscheinlich verbessert wurde. Wenn ich also auf den Button klicke, wird der Absatz sofort umbenannt (noch nicht getestet, ob das auf Seitenebene ebenfalls geht).
Edit: Jetzt gerade ging es wieder nicht - ich musste einen anderen Absatz im Baum anklicken, damit der Name der umbenannten Absatzes angezeigt wurde. Komisch ...
ABER: Wie komme ich an den Inhalt der st_textarea_1 in den anderen Sprachen? Und zwar an die editierten, ggf. noch nicht auf dem Server gespeicherten. Über das mapping des Feldes auf die Variable "headline" (in <PARAMS>) komme ich an die aktuelle Sprache. Über "element" komme ich nur auf das, was auf dem Server gespeichert ist? Ich habe ja schon versucht, nur #field zu mappen, komme aber nicht weiter.
Die Erwartung der User ist: Absatz neu anlegen (Standardname = Name des Absatztemplates). Alle Sprachen der Headline pflegen, Button, Klicken => Absatz wird umbenannt. Dann mit dem nächsten Absatz weitermachen. Den Leuten zu erläutern, wann sie zwischenspeichern müssen, damit das klappt, habe ich schon versucht - hoffnungslos
Danke & Grüße,
Arndt
Hi,
nur ein kurzer Hinweis, weil ich es in deinem Codebeispiel gesehen habe.
CMSDialog.showInfoDialog("Renamed language " + language.toString() + " to \"" + newname + "\"");
CMSDialog ist KEINE Api.
Es gibt aber bereits in 4.2 API für einen solchen Dialog, der auch in Webedit funktionieren würde und zwar die RequestOperation.
Hallo Arndt,
anhand deiner Angaben habe ich das ganze noch einmal nachgestellt und bin nun ein wenig verwirrt bzgl. deiner Erwartungen. Bei mir verhält sich der Client genau deinen Wünschen entsprechend - zumindest so, wie ich sie verstehe.
Ich bin wie folgt vorgegangen:
1. Ich habe zwei neue Absätze (mein Test-Absatz // mein Test-Absatz 2) angelegt
die Seite ist danach im Bearbeitungsmodus, die Felder Überschrift und Headline sind leer
2. Nach einer Eingabe in den beiden Felder (ohne Zwischenspeicherung!) und einem Klick auf den Button in DE und EN (in dem Absatz "mein Test-Absatz") bekam ich jeweils einen Dialog, dass der Anzeigename für die jeweilige Sprache geändert wurde. Beide habe ich bestätigt.
3. Ein Klick auf F9 zeigt, dass die Anzeigenamen des Absatzes "mein Test-Absatz" für DE und EN geändert wurden, obwohl im Baum noch die ursprünglichen Anzeigenamen (DE) angezeigt werden.
4. Ein Wechsel ( ohne Zwischenspeicherung !) auf den nächsten Absatz "mein Test-Absatz 2" aktualisiert die Ansicht im Baum für den ersten Absatz. Der geänderte Anzeigename für DE ist nun sichtbar. Für den zweiten Absatz habe ich die vorhergehenden Schritte wiederholt. Das Verhalten ist erwartungsgemäß gleich.
Bis zu diesem Schritt wurde noch keine einzige Speicherung durchgeführt. Würden die Eingaben nun verworfen (STRG + Shift + E), würden wieder die initialen Anzeigenamen angezeigt. Eine Speicherung oder ein verlassen des Bearbeitungsmodus speichert die Eingaben hingegen und persistiert sie.
Mir ist nicht klar, an welcher Stelle der Client sich nun nicht so verhält, wie es gewüscht ist. :smileyconfused:
LG Michaela
P.S.: Bitte auch den Hinweis bzgl der Verwendung von CMSDialog berücksichtigen.
Hallo Michaela,
vielen Dank für Deine Mühe. Ich glaube, wir nähern uns dem Problem an. Nebenbei: Hier geht es nicht nur um das Einzelproblem - diese Mechanismen stehen stellvertretend für einen Haufen von kleinen Usability-Verbesserungen, die man über einfach einfache Scripte in das FS-Interface einfließen lassen könnte, mit großer Zeitersparnis für die User. Nur, dass nicht der Eindruck entsteht, ich mache aus einer Mücke einen Elefanten. Dazu unten mehr.
Ich habe die Lösung schon im Einsatz gehabt (ohne den CMSDialog - den habe ich nur zum Debuggen aus einem alten Script von Euch genommen, Hinweis ist angekommen ). Gescheitert ist das an zwei Sachen, die auch Du erwähnst:
Michaela Pahl schrieb:
[...] Klick auf den Button in DE und EN (in dem Absatz "mein Test-Absatz") bekam ich jeweils einen Dialog [...]
Bestenfalls haben die Leute vergessen, in jeder Sprache auf den Knopf zu drücken (=Datenmüll), schlechtestenfalls waren sie genervt und haben gefragt: "warum kann das System das nicht auf einmal".
Michaela Pahl schrieb:
Ein Wechsel ( ohne Zwischenspeicherung !) auf den nächsten Absatz "mein Test-Absatz 2" aktualisiert die Ansicht im Baum für den ersten Absatz.
Das kam zu dem Punkt oben noch dazu. Rückmeldung der Redakteure: "Das ist zu verwirrend, wenn ich erst auf einen anderen Knoten gehen muss, und die Namensänderung nicht gleich sehe. Warum kann das System das nicht gleich machen?"
Deshalb meine beiden Anliegen: Setzen aller Sprachen (aus den verschieden sprachlichen Feldern) bei nur einem Klick auf den Button gleichzeitig (egal auf welcher Sprache), und sofortige Aktualisierung des Namens im Baum beim Button-Klick. Glaub mir: Ich würde da nicht so penetrant nachhaken, wenn ich nicht gesehen hätte, dass die an sich gute Idee letztendlich an diesen Kleinigkeiten scheitert. Ich hab es im Produktivsystem dann wieder abgeschaltet, weil die "Kleinigkeiten" dem System angelastet wurden.
Wenn man drüber nachdenkt, sind diese Kleinigkeiten genau das, was ein iOS von Android unterscheidet: Beide erreichen dasselbe, aber bei iOS herrscht die kompromisslose Usability.
LG,
Arndt
Hallo Arndt,
langsam wird es kompliziert. Nach einigem internen Hin- und Her-Überlegen scheint das (komplette) gewünschte Verhalten nur über einen anderen Ansatz zu funktionieren.
Würde der Button per Skript einen Dialog öffnen, der die Eingabefelder für die verschiedenen Sprachen enthält, könnte das Skript die Werte nach der Bestätigung der Werte durch das Schließen des Dialogs die eingegeben Werte weiter verarbeiten und entsprechend die unterschiedlichen Anzeigenamen setzen.
(Getestet habe ich das nicht.)
Um Dein voriges Posting nicht zu übergehen, noch einige weitere Worte
1. Anliegen
Setzen aller Sprachen (aus den verschieden sprachlichen Feldern) bei nur einem Klick auf den Button gleichzeitig (egal auf welcher Sprache),
Dieses Anliegen ist umsetzbar, wenn der Absatz vorher lediglich einmal nach dem Befüllen aller Felder und vor dem Klicken des Buttons gespeichert würde.
Also: Absatz anlegen, Headline-Feld für alle Sprachen eines Absatzes füllen, Button klicken -> die unterschiedlichen Anzeigenamen des Absatzes werden entsprechend der sprachabhängigen Eingaben geändert. Bsp: Anzeigename (DE): Überschrift // Anzeigename (EN): Headline
Dein Skript müsste dafür wie folgt angepasst werden:
(Danke an dieser Stelle an Rouven!)
//!BeanShell
import de.espirit.firstspirit.common.gui.*;
languages = element.getProject().getLanguages();
for(lang:languages){
langinfo = element.getLanguageInfo(lang);
formField = element.getFormData().get(lang, headline.getName());
langinfo.setDisplayName(formField.get());
}
2. Anliegen
sofortige Aktualisierung des Namens im Baum beim Button-Klick
In diesem Fall kann ich mich nur selbst zitieren:
[...] Alle Änderungen werden erst durch ein Speichern bzw. durch ein Verlassen des Bearbeitungsmodus (inkl. Speicherung) übernommen und persistiert. Daher wird auch der geänderte Anzeigename erst durch die entsprechende Handlung angezeigt/aktualisiert.
Andernfalls würde der [angezeigte] Anzeigename [im Baum] einen nicht persistierten Wert annehmen. Würden die vorgenommen und noch nicht gespeicherten Änderungen anschließend verworfen (über STRG+Shift+E), hätte der Anzeigename eventuell gar keinen Wert mehr, da der ursprüngliche Wert durch den inzwischen verworfenen Wert überschrieben wurde und somit ebenfalls nicht mehr existiert. Dies ist nicht wünschenswert und daher auch nicht möglich.
Die Usability besteht also darin, die Verwendung von nicht persistenten Daten und einem damit einhergehenden potentiellen Datenverlust zu vermeiden bzw zu verhindern. Ein potentieller Datenverlust dürfte für einen Redakteur das größere Übel sein, als die Datensicherung durch ein gelegentliches Speichern.
LG Michaela
Hi,
am gleichzeitigen Speichern soll es nicht scheitern - ich werde den anderen Ansatz mal ausprobieren. Ein Speichervorgang mehr oder weniger macht ja den Kohl nicht fett. Daraus muss ich also schließen, dass das Script nur Zugriff auf die (gespeicherte) formData hat, auf die nicht gespeicherten Daten des Formulars aber nur im aktuellen Sprach-Tab über das Mapping? Wie gesagt, das Verständnis ist mir auch für andere mögliche Anwendungen wichtig.
Den zweiten Punkt mit der Persistenz verstehe ich nicht. Nimm mal folgenden Fall:
Da sehe ich irgendwie nicht ein, dass mein Script nicht dasselbe (Schritt 4) machen darf, was der F9-Dialog machen darf. Wenn das darin begründet ist, dass es da keine Schnittstelle in der API gibt, dann wäre mir das einen Feature-Request wert. Den mache ich aber natürlich nicht, wenn Du das mit der Persistenz in meinen kleinen Kopf bekommst. :smileycry:
Und zu guter letzt: Den Hinweis mit dem Datenverlust werde ich mir zu eigen machen, auch wenn der für die Redakteure wahrscheinlich wie eine Drohung klingt: "Wenn Ihr nicht Ruhe gebt, lass ich Eure Daten verschwinden ..." :smileymischief:
LG,
Arndt