robert
I'm new here

Variable "element" steht bei der Verwendung von FS_BUTTON im Content Creator nicht zur Verfügung

Jump to solution

Hallo,

die Frage stammt aus einem Helpdesk-Ticket und kann jetzt hier vielleicht besser weiterdiskutiert werden.

Wir haben ein Formular zum Anlegen von News in einer Datenquelle. Das Formular enthält Pflichtfelder. Wenn die News in einer Sprache angelegt wurde, lässt sie sich noch nicht speichern, weil die Pflichtfelder in allen Sprachen gefüllt sein müssen. Daraus ist der Kundenwunsch entstanden, dass es eine Möglichkeit geben soll, die Formularfelder aus einer Sprache in alle Sprachen zu übertragen.
Dafür habe ich einen FS_BUTTON ins Formular eingebaut, der über eine Executable-Klasse diese Funktionalität bereitstellen soll. Der Button sieht im Formular dann so aus:


    <FS_BUTTON
      name="tt_button"
      onClick="class:de.xxx.FormCopyFieldsToAllLanguages"
      style="button"
      useLanguages="no">
      <LANGINFOS>
        <LANGINFO lang="*" label="Copy news to all languages"/>
        <LANGINFO lang="DE" label="News in alle Sprachen übernehmen"/>
      </LANGINFOS>
      <PARAMS>
        <PARAM name="tt_headline">#field.tt_headline</PARAM>
        <PARAM name="tt_date">#field.tt_date</PARAM>
        <PARAM name="tt_category">#field.tt_category</PARAM>
        <PARAM name="tt_teaser">#field.tt_teaser</PARAM>
        <PARAM name="tt_text">#field.tt_text</PARAM>
        <PARAM name="tt_image">#field.tt_image</PARAM>
        <PARAM name="tt_image_caption">#field.tt_image_caption</PARAM>
      </PARAMS>
    </FS_BUTTON>

Über die PARAMS habe ich damit schon die Werte aller Formularfelder der aktuellen Sprache in der Executable zur Verfügung.
Und das entscheidende Code-Stück aus der Executable für das Kopieren sieht wie folgt aus:

DataProvider element = (DataProvider)properties.get("element");
Iterator<Language> languageInterator = element.getProject().getLanguages().iterator();
while (languageInterator.hasNext()) {
  Language formLanguage = languageInterator.next();

  //initialize operation
  OpenElementDataFormOperation operation = context.requireSpecialist(OperationAgent.TYPE).getOperation(OpenElementDataFormOperation.TYPE);
  operation.setLanguage(formLanguage);

  //get form data
  FormData formData = element.getFormData();

  propertyKeysIterator = properties.keySet().iterator();
  while (propertyKeysIterator.hasNext()) {
    String propertyKey = propertyKeysIterator.next();
    Object propertyValue = properties.get(propertyKey);
    if (propertyValue instanceof ApiRemoteFormField<?>) {
      FormField<?> formField = (FormField<?>) properties.get(propertyKey);
      Object formFieldValue = formField.get();
      formData.get(formLanguage, propertyKey).set(formFieldValue);
    }
  }

  //set filled remoteFormData to operation and dataset
  operation.setFormData(formData);
  element.setFormData(formData);

  //execute operation
  operation.perform(element);
}

Das funktioniert im SiteArchitect einwandfrei.
Das entscheidende an der OpenElementDataFormOperation ist der DataProvider element, von dem das FormData-Objekt gezogen und auf dem die Operation ausgeführt wird. Dieser DataProvider steht im SiteArchitect in den Properties zur Verfügung, die an die execute-Methode der Executable übergeben werden.
Und genau dieser DataProvider steht bei der Verwendung im ContentCreator nicht zur Verfügung. In den Properties der execute-Methode ist das Attribut "element" nicht enthalten. Ich habe die Ausweichlösung über "element = (DataProvider) webUiAgent.getPreviewElement();" probiert, aber das hilft nichts. "webUiAgent.getPreviewElement()" liefert einen DataProvider für die im ContentCreator offene Seite. Die News legen wir aber über die Funktion zum Anlegen eines neuen Datensatzes im Inhalte-Bereich der ContentCreator Menüleiste an. Der Dialog zum Anlegen des Datensatzes wird als modales Fenster über der im ContentCreator offenen Seite eingeblendet. "webUiAgent.getPreviewElement()" reagiert aber nicht auf das modale Fenster mit dem Anlegen-Dialog, sondern liefert das Preview-Element für die Seite darunter. Und das ist dann natürlich der falsche DataProvider für die Executable und die Kopierfunktion.

Und ich suche jetzt nach einer Möglichkeit, wie ich auch im ContentCreator an einen geeigneten DataProvider für meine News-Datenquelle herankomme, um damit die OpenElementDataFormOperation ausführen zu können. Und ich hatte mich in dem Zusammenhang gewundert, dass beim Aufruf der Executable über den ContentCreator das aktuelle Element nicht mit in den Executable-Properties zur Verfügung steht. So wie es im SiteArchitect der Fall ist.

Viele Grüße,

Robert

0 Kudos
1 Solution

Accepted Solutions

Hallo Robert,

Robert Rödel schrieb:

derweil sind die Pflichtfeldprüfungen nicht mehr über Regeln realisiert, da die ebenfalls im ContentCreator zu Problemen geführt hatten.

was für Probleme sind dies denn? Sind die bei uns gemeldet? Regeln funktionieren zum größten Teil im SiteArchitect und ContentCreator gleichermaßen. Wenn hier etwas nicht tut, bitte im Technical Support Bescheid geben.

Aktuell wird der Parameter "allowEmpty" an den betroffenen Eingabekomponenten gesetzt. Ob der Parameter auch per Toggle aktiviert werden kann, kann ich gerade nicht sagen. Wie sich das bei sprachabhängigen Eingabekomponenten verhalten würde, kann ich auch noch nicht beurteilen. Aber selbst wenn es technisch möglich wäre, stellt sich immer noch die Frage, wie man dafür sorgt, dass die News in allen Sprachen gepflegt ist. Das wird durch fehlende Pflichtfelder eher noch verkompliziert. Das Kopieren von Formularinhalten einer Sprache in alle anderen Sprachen ist eine Komfortfunktion, die es derweil in FirstSpirit nicht gibt. Auf der anderen Seite stellt sich aber natürlich auch die Frage, ob beispielsweise eine News in englischer Sprache mit deutschen Inhalten (nach Nutzen der Kopierfunktion) so viel Sinn ergibt.

Also, der Lösungsansatz über einen Toggle wird uns hier vermutlich nicht wirklich weiterbringen.

Dieser Vorschlag funktioniert nur mit Regeln. Die alte Nutzung via Parameter im GOM ermöglichen keinerlei dynamische Nutzung.

Innerhalb von Regeln kann auf die aktuelle Sprache geprüft werden. Eine weitere prüfbare Eigenschaft ist, ob der Haken "Vollständig übersetzt" gesetzt wurde. Hieraus ergeben sich einige "Toggle"-Möglichkeiten. Alternativ kann im Formular natürlich auch ein (versteckter) Toggle eingebaut werden. Hintergrund des Vorschlags war vermutlich, auf diesem Weg das Speichern zu ermöglichen, obwohl nicht alle Sprachen gepflegt sind, und in einem nachgelagerten Schritt (Arbeitsablauf, Freigabe) das Kopieren der Inhalte vorzunehmen.

Was war der zweite Vorschlag? Der ist jetzt irgendwie verloren gegangen.

Das wäre die Variante, ein eigenes Plug-in zu erstellen, über das die Redakteure das Anlegen von News im ContentCreator starten. Da hier eine eigene Klasse dahinter liegen kann, hat man für einen solchen Prozess die volle Kontrolle darüber, was mit den Eingaben des Redakteurs nach Abschicken des Formulars passiert. Ob diese Variante für eure Zwecke passt, kann ich nicht beurteilen.

Beste Grüße

Stefan

View solution in original post

0 Kudos
6 Replies
robert
I'm new here

Und hier noch die letzten Erkenntnisse aus dem Helpdesk-Ticket.

##

Es wurde vermutlich beim anlegen einer News getestet. Hierbei verhalten sich beide Clients unterschiedlich. Im SA wird erst ein leerer Datensatz angelegt und dann das Formular angezeigt. Im CC wird das Formular angezeigt und erst beim Speichern ein neuer Datensatz erzeugt.
Ich würde eher über eine Lösung nachdenken, in der die Regeln per default deaktiviert sind per Toggle aktiviert werden (Analog zur Seite vollständig übersetzt).

##

Nur mal so als Rückfrage: Das Erzeugen neuer News erfolgt im CC über welchen Weg? Aus einem anderen Formular heraus? Über eine eigene Erweiterung im Menü? Der Weg, der hier von HLP beschrieben wird, könnte ja theoretisch auch direkt als Plug-in bereitgestellt werden und dann hätten sie die volle Kontrolle über den Formulardatenprozess mit obigem Ansatz.

##

0 Kudos
##

Nur mal so als Rückfrage: Das Erzeugen neuer News erfolgt im CC über welchen Weg? Aus einem anderen Formular heraus? Über eine eigene Erweiterung im Menü? Der Weg, der hier von HLP beschrieben wird, könnte ja theoretisch auch direkt als Plug-in bereitgestellt werden und dann hätten sie die volle Kontrolle über den Formulardatenprozess mit obigem Ansatz.

##

Für die Tabellenvorlage zur Datenquelle wurde das Flag "Im ContentCreator verwendbar" gesetzt. Damit taucht der Dialog zum Erzeugen neuer News im ContentCreator im Inhalte-Bereich der  Menüleiste auf.

0 Kudos

Hi Robert,

kannst du mit den beiden Vorschlägen im Rahmen eures Projektes etwas anfangen oder benötigst du hier weitere Beratung?

Gruß

Stefan

0 Kudos

Hallo Stefan,

derweil sind die Pflichtfeldprüfungen nicht mehr über Regeln realisiert, da die ebenfalls im ContentCreator zu Problemen geführt hatten. Aktuell wird der Parameter "allowEmpty" an den betroffenen Eingabekomponenten gesetzt. Ob der Parameter auch per Toggle aktiviert werden kann, kann ich gerade nicht sagen. Wie sich das bei sprachabhängigen Eingabekomponenten verhalten würde, kann ich auch noch nicht beurteilen. Aber selbst wenn es technisch möglich wäre, stellt sich immer noch die Frage, wie man dafür sorgt, dass die News in allen Sprachen gepflegt ist. Das wird durch fehlende Pflichtfelder eher noch verkompliziert. Das Kopieren von Formularinhalten einer Sprache in alle anderen Sprachen ist eine Komfortfunktion, die es derweil in FirstSpirit nicht gibt. Auf der anderen Seite stellt sich aber natürlich auch die Frage, ob beispielsweise eine News in englischer Sprache mit deutschen Inhalten (nach Nutzen der Kopierfunktion) so viel Sinn ergibt.

Also, der Lösungsansatz über einen Toggle wird uns hier vermutlich nicht wirklich weiterbringen.

Was war der zweite Vorschlag? Der ist jetzt irgendwie verloren gegangen.

Viele Grüße,

Robert

0 Kudos

Hallo Robert,

Robert Rödel schrieb:

derweil sind die Pflichtfeldprüfungen nicht mehr über Regeln realisiert, da die ebenfalls im ContentCreator zu Problemen geführt hatten.

was für Probleme sind dies denn? Sind die bei uns gemeldet? Regeln funktionieren zum größten Teil im SiteArchitect und ContentCreator gleichermaßen. Wenn hier etwas nicht tut, bitte im Technical Support Bescheid geben.

Aktuell wird der Parameter "allowEmpty" an den betroffenen Eingabekomponenten gesetzt. Ob der Parameter auch per Toggle aktiviert werden kann, kann ich gerade nicht sagen. Wie sich das bei sprachabhängigen Eingabekomponenten verhalten würde, kann ich auch noch nicht beurteilen. Aber selbst wenn es technisch möglich wäre, stellt sich immer noch die Frage, wie man dafür sorgt, dass die News in allen Sprachen gepflegt ist. Das wird durch fehlende Pflichtfelder eher noch verkompliziert. Das Kopieren von Formularinhalten einer Sprache in alle anderen Sprachen ist eine Komfortfunktion, die es derweil in FirstSpirit nicht gibt. Auf der anderen Seite stellt sich aber natürlich auch die Frage, ob beispielsweise eine News in englischer Sprache mit deutschen Inhalten (nach Nutzen der Kopierfunktion) so viel Sinn ergibt.

Also, der Lösungsansatz über einen Toggle wird uns hier vermutlich nicht wirklich weiterbringen.

Dieser Vorschlag funktioniert nur mit Regeln. Die alte Nutzung via Parameter im GOM ermöglichen keinerlei dynamische Nutzung.

Innerhalb von Regeln kann auf die aktuelle Sprache geprüft werden. Eine weitere prüfbare Eigenschaft ist, ob der Haken "Vollständig übersetzt" gesetzt wurde. Hieraus ergeben sich einige "Toggle"-Möglichkeiten. Alternativ kann im Formular natürlich auch ein (versteckter) Toggle eingebaut werden. Hintergrund des Vorschlags war vermutlich, auf diesem Weg das Speichern zu ermöglichen, obwohl nicht alle Sprachen gepflegt sind, und in einem nachgelagerten Schritt (Arbeitsablauf, Freigabe) das Kopieren der Inhalte vorzunehmen.

Was war der zweite Vorschlag? Der ist jetzt irgendwie verloren gegangen.

Das wäre die Variante, ein eigenes Plug-in zu erstellen, über das die Redakteure das Anlegen von News im ContentCreator starten. Da hier eine eigene Klasse dahinter liegen kann, hat man für einen solchen Prozess die volle Kontrolle darüber, was mit den Eingaben des Redakteurs nach Abschicken des Formulars passiert. Ob diese Variante für eure Zwecke passt, kann ich nicht beurteilen.

Beste Grüße

Stefan

0 Kudos

Hallo Stefan,

wie es aussieht, wird derweil gar keine Lösung mehr umgesetzt. Falls doch, schaue ich mir die Vorschläge noch einmal im Detail an. Insofern Danke dafür und ich schließe die Frage als "Beantwortet" ab.

Viele Grüße,

Robert

0 Kudos