Hi again 
Arndt Bär schrieb:
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?
Das war das vorhin beobachtete Verhalten beim Testen des obrigen Skripts. Wurden die Werte vorher gespeichert, funktioniert das Skript wie gewünscht. Waren die Werte nicht gespeichert, kam "null" zurück.
Den zweiten Punkt mit der Persistenz verstehe ich nicht. Nimm mal folgenden Fall:
- Dokument bearbeiten
- Absatz im Baum markieren
- F9 - Anzeigename ändern
- Dialog beenden - Anzeigename wird sofort aktualisiert
- STRG+SHIFT+E - Anzeigename wird auf den alten Stand zurückgesetzt
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:
Hm, nun hast Du mich kalt erwischt... Dass der Dialog in Schritt 4 bereits aktualisiert wird, hatte ich bei mir übersehen, aber Du hast Recht. Ich hab das extra nochmal nachgeklickt. Es gibt bereits intern einen ähnlichen Feature Request (#134247), der sich allerdings auf Datensätze bezieht. Den Hinweis, dass der Baum sich aktualisiert, wenn der ausgewählte Knoten aktualisiert wird, hatte ich mit einer Speicherung gleichgesetzt.
Hm, ich werde da nächste Woche noch einmal draufschauen
Für den Moment wünsche ich jedoch erstmal ein schönes WE.
LG Michaela
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
