Accepted Solutions
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 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 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
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
