steamframe
I'm new here

Regeln FS_Reference Wert auf Übersetzung prüfen

Jump to solution

Hallo zusammen,

ich habe folgendes Problem. Ich möchte den Wert dieser FS_REFERENCE:

  <FS_REFERENCE

    name="st_pageref"

    allowEmpty="yes"

    hFill="yes"

    imagePreview="no"

    sections="no"

    upload="no"

    useLanguages="no">

    <FILTER>

      <ALLOW type="pageref"/>

    </FILTER>

    <LANGINFOS>

      <LANGINFO lang="*" label="Page reference"/>

      <LANGINFO lang="DE" label="Seitenreferenz"/>

    </LANGINFOS>

    <PROJECTS>

      <LOCAL name=".">

        <SOURCES>

          <FOLDER name="root" store="sitestore"/>

        </SOURCES>

      </LOCAL>

    </PROJECTS>

  </FS_REFERENCE>

überprüfen. Und zwar soll der Wert, also die ausgewählte Seite übersetzt sein. Meine Idee ging in diese Richtung:

<RULE>

    <IF>

        <NOT>

            <PROPERTY name="EMPTY" source="st_pageref"/>

        </NOT>

    </IF>

    <WITH>

        <AND>

            <PROPERTY name="VALUE" source="st_pageref"/>

            <PROPERTY name="TRANSLATED" source="#global"/>

            <PROPERTY name="INCLUDED" source="#global"/>

        </AND>

    </WITH>

    <DO>

        <VALIDATION scope="RELEASE">

            <PROPERTY name="VALID" source="st_pageref"/>

            <MESSAGE lang="*" text="Seite nicht übersetzt!"/>

        </VALIDATION>

    </DO>

</RULE>


Das funktioniert leider nicht richtig. Ich denke, das es auch gar nicht möglich ist das zu überprüfen?
Eine zweite Idee wäre das über ein script beim Deployment zu lösen. Dann müsste man aber rekursiv über alle Links laufen und checken ob der Link in der Sprache auch generiert wurde.
Hat jemand eine andere/bessere Idee?

0 Kudos
1 Solution

Accepted Solutions
mbergmann
Crownpeak employee

Hallo Jörn,

ich verstehe die Anforderung so, dass verhindert werden soll, dass auf noch nicht als übersetzt markierte Seiten verlinkt wird.

Das lässt sich über die Regeln nicht abbilden und ist tatsächlich alles andere als trivial.

Mögliche Ansätze die mir einfallen (ggf. auch in Kombination) - allerdings alle mit Vor- und Nachteilen:

Prüfung im Workflow

Prüfung über ein entsprechendes Skript bzw. besser Modul (Executable) im Freigabe-Worflow. Die Idee wäre, an passender Stelle im Workflow die ausgehenden Referenzen der Seite und Absätze zu durchlaufen und deren Übersetzungsflag zu prüfen.

Hinweis in der Vorschau

Eine entsprechende Prüfung könnte auch in der Vorschau (d.h. über Template-Mittel) erfolgen, indem (natürlich nur in der Vorschau) eine entsprechende Warnung quasi ins HTML gerendert wird. Das ist (auch bei anderen komplexeren Dingen) ein recht üblicher Weg und da gibt es diverse Ansätze. Ich mache sowas ganz gerne über das Rendern von entsprechenden data-Attributen an die passenden Stellen, die dann über ein globales JS ausgewertet bzw. gesammelt und dann z.B. ganz oben auf der Seite in einer Art "Infobox" dargestellt werden. Hier kann man natürlich keine Korrektur erzwingen.

Erzeugen von Generierungswarnungen bzw. -fehlern

Letztlich auch wieder über Template-Mittel. Wenn festgestellt wird, dass es "ein Problem gibt", könntest du "mutwillig" einen Generierungsfehler erzeugen, z.B. mit

$CMS_SET(void, #global.logError("This page links to another page that is marked as NOT translated"))$

Da dies technisch einen "normalen" Generierungsfehler erzeugt, kann man darauf im Auftrag reagieren und z.B. den Deployment-Task nicht ausführen.

Sammeln von Informationen während der Generierung

Du könntest während der Generierung auch entsprechende Infos im ScheduleContext sammeln (geht mit Template-Mitteln) und dann über einen nachfolgenden Skript-Task im Auftrag "passend behandeln".

Allgemeines

Ob das alles rein von der Logik her klappt, hängt letztlich auch davon ab, wie eure Generierungsaufträge aufgebaut sind - insbesonderen, ob die immer alle Sprachen (oder zumindest immer dieselben) erzeugen. d.h. das funktioniert natürlich nur, wenn zum jeweiligen Zeitpunkt überhaupt schon eindeutig entschieden werden kann, ob tatsächlich ein Link auf eine "ungültige" Seite (in deinem Sinn) erzeugt wird. In dem Zusammenhang muss man auch bedenken, dass selbst ein "Übersetzt"-Haken alleine noch nicht unbedingt etwas aussagt - der kann ja ggf. nur im Current-Stand da sein aber (noch) nicht im Freigabestand, d.h. die Zielseite wurde nach dem Setzen des Hakens noch nicht wieder freigegeben.

Allgemein besteht natürlich die Gefahr, dass ein Link ja sogar von "gültig" auf "ungültig" wechseln kann, indem der Übersetzt-Haken einer Seite später entfernt wird. Hier müsste man ja sogar eine Art "umgekehrte" Prüfung (z.B. in den Freigabe-Workflow) einbauen und prüfen, ob es eingehende Referenzen auf die aktuelle Seite gibt, wenn sie nicht übersetzt ist - was aber wiederum nur ein echtes Problem wäre wenn die Seite aus der die eingehende Referenz kommt, selbst als "übersetzt" markiert ist...

Wirklich sicher (also weder false positives oder false negatives) kann das Problem IMHO nur im Rahmen der Generierung erkannt werden, da sich - zumindest theoretisch - einige Varianten von "Henne-Ei"-Problemen konstruieren lassen wie z.B. das schon erwähnte Problem des Freigabe- bzw. Änderungszeitpunktes einzelner Quell- bzw. Ziel-Seiten. Denn letztlich ist nur während der Generierung wirklich klar, was nun wirklich mit welchem Stand erzeugt wird. Im Umkehrschluss heißt das natürlich, dass für den Redakteur während der Bearbeitung einer Seite meiner Meinung nach höchstens potentielle Probleme erkannt werden können, auf die man ihn hinweisen kann.

Übrigens - nur als Hinweis: Du benutzt bei deinem Versuch auch die Property INCLUDED. Die steht ja für die Sprachhaken an einzelnen Absätzen. Die haben allerdings von der Idee her mit "Übersetzungen" nichts zu tun sondern sind reine An/Aus-Schalter, um einzelne Absätze in einzelnen Sprachen auszublenden.

Viele Grüße

Michael

View solution in original post

0 Kudos
4 Replies
mbergmann
Crownpeak employee

Hallo Jörn,

ich verstehe die Anforderung so, dass verhindert werden soll, dass auf noch nicht als übersetzt markierte Seiten verlinkt wird.

Das lässt sich über die Regeln nicht abbilden und ist tatsächlich alles andere als trivial.

Mögliche Ansätze die mir einfallen (ggf. auch in Kombination) - allerdings alle mit Vor- und Nachteilen:

Prüfung im Workflow

Prüfung über ein entsprechendes Skript bzw. besser Modul (Executable) im Freigabe-Worflow. Die Idee wäre, an passender Stelle im Workflow die ausgehenden Referenzen der Seite und Absätze zu durchlaufen und deren Übersetzungsflag zu prüfen.

Hinweis in der Vorschau

Eine entsprechende Prüfung könnte auch in der Vorschau (d.h. über Template-Mittel) erfolgen, indem (natürlich nur in der Vorschau) eine entsprechende Warnung quasi ins HTML gerendert wird. Das ist (auch bei anderen komplexeren Dingen) ein recht üblicher Weg und da gibt es diverse Ansätze. Ich mache sowas ganz gerne über das Rendern von entsprechenden data-Attributen an die passenden Stellen, die dann über ein globales JS ausgewertet bzw. gesammelt und dann z.B. ganz oben auf der Seite in einer Art "Infobox" dargestellt werden. Hier kann man natürlich keine Korrektur erzwingen.

Erzeugen von Generierungswarnungen bzw. -fehlern

Letztlich auch wieder über Template-Mittel. Wenn festgestellt wird, dass es "ein Problem gibt", könntest du "mutwillig" einen Generierungsfehler erzeugen, z.B. mit

$CMS_SET(void, #global.logError("This page links to another page that is marked as NOT translated"))$

Da dies technisch einen "normalen" Generierungsfehler erzeugt, kann man darauf im Auftrag reagieren und z.B. den Deployment-Task nicht ausführen.

Sammeln von Informationen während der Generierung

Du könntest während der Generierung auch entsprechende Infos im ScheduleContext sammeln (geht mit Template-Mitteln) und dann über einen nachfolgenden Skript-Task im Auftrag "passend behandeln".

Allgemeines

Ob das alles rein von der Logik her klappt, hängt letztlich auch davon ab, wie eure Generierungsaufträge aufgebaut sind - insbesonderen, ob die immer alle Sprachen (oder zumindest immer dieselben) erzeugen. d.h. das funktioniert natürlich nur, wenn zum jeweiligen Zeitpunkt überhaupt schon eindeutig entschieden werden kann, ob tatsächlich ein Link auf eine "ungültige" Seite (in deinem Sinn) erzeugt wird. In dem Zusammenhang muss man auch bedenken, dass selbst ein "Übersetzt"-Haken alleine noch nicht unbedingt etwas aussagt - der kann ja ggf. nur im Current-Stand da sein aber (noch) nicht im Freigabestand, d.h. die Zielseite wurde nach dem Setzen des Hakens noch nicht wieder freigegeben.

Allgemein besteht natürlich die Gefahr, dass ein Link ja sogar von "gültig" auf "ungültig" wechseln kann, indem der Übersetzt-Haken einer Seite später entfernt wird. Hier müsste man ja sogar eine Art "umgekehrte" Prüfung (z.B. in den Freigabe-Workflow) einbauen und prüfen, ob es eingehende Referenzen auf die aktuelle Seite gibt, wenn sie nicht übersetzt ist - was aber wiederum nur ein echtes Problem wäre wenn die Seite aus der die eingehende Referenz kommt, selbst als "übersetzt" markiert ist...

Wirklich sicher (also weder false positives oder false negatives) kann das Problem IMHO nur im Rahmen der Generierung erkannt werden, da sich - zumindest theoretisch - einige Varianten von "Henne-Ei"-Problemen konstruieren lassen wie z.B. das schon erwähnte Problem des Freigabe- bzw. Änderungszeitpunktes einzelner Quell- bzw. Ziel-Seiten. Denn letztlich ist nur während der Generierung wirklich klar, was nun wirklich mit welchem Stand erzeugt wird. Im Umkehrschluss heißt das natürlich, dass für den Redakteur während der Bearbeitung einer Seite meiner Meinung nach höchstens potentielle Probleme erkannt werden können, auf die man ihn hinweisen kann.

Übrigens - nur als Hinweis: Du benutzt bei deinem Versuch auch die Property INCLUDED. Die steht ja für die Sprachhaken an einzelnen Absätzen. Die haben allerdings von der Idee her mit "Übersetzungen" nichts zu tun sondern sind reine An/Aus-Schalter, um einzelne Absätze in einzelnen Sprachen auszublenden.

Viele Grüße

Michael

0 Kudos

Hallo Michael,


danke für deine Ausführlichen Gedanken! Wir haben das Besprochen und letztendlich entschieden, es doch in die Hände des Redakteurs zu legen und mit 2 Klicks zu checken, ob die Seite überhaupt übersetzt ist. Ein wirklich 100% Lösung wird wahrscheinlich schwer zu erreichen sein.

VG

0 Kudos

Hallo Jörn,

sofern die Usability für Euch in Ordnung geht wäre es möglich, die Auswahl des Redakteurs über ein Button-Skript zu validieren. Eine Validierung über einen Workflow wäre m. E. zwar die elegantere Variante, aber sofern keine Workflows eingesetzt werden oder aus sonstigen Gründen Workflows als Lösungsoption entfallen wäre die folgende Variante möglich:

Formular Absatzvorlage:

<CMS_MODULE>

  <CMS_GROUP tabs="none">

    <LANGINFOS>

      <LANGINFO lang="*" label="Page reference"/>

      <LANGINFO lang="DE" label="Seitenreferenz"/>

    </LANGINFOS>

    <FS_REFERENCE

      name="st_pageref"

      allowEmpty="yes"

      hFill="yes"

      imagePreview="no"

      sections="no"

      upload="no"

      useLanguages="no">

      <FILTER>

        <ALLOW type="pageref"/>

      </FILTER>

      <LANGINFOS>

        <LANGINFO lang="*" label="Page reference"/>

        <LANGINFO lang="DE" label="Seitenreferenz"/>

      </LANGINFOS>

      <PROJECTS>

        <LOCAL name=".">

          <SOURCES>

            <FOLDER name="root" store="sitestore"/>

          </SOURCES>

        </LOCAL>

      </PROJECTS>

    </FS_REFERENCE>

    <FS_REFERENCE

      name="st_pageref_hidden"

      allowEmpty="yes"

      hFill="yes"

      hidden="yes"

      imagePreview="no"

      sections="no"

      upload="no"

      useLanguages="no">

      <FILTER>

        <ALLOW type="pageref"/>

      </FILTER>

      <LANGINFOS>

        <LANGINFO lang="*" label="Page reference (hidden)"/>

        <LANGINFO lang="DE" label="Seitenreferenz (versteckt)"/>

      </LANGINFOS>

      <PROJECTS>

        <LOCAL name=".">

          <SOURCES>

            <FOLDER name="root" store="sitestore"/>

          </SOURCES>

        </LOCAL>

      </PROJECTS>

    </FS_REFERENCE>

    <CMS_INPUT_TOGGLE name="st_isTranslatedAndReleased" hidden="yes" useLanguages="no">

      <LANGINFOS>

        <LANGINFO lang="*" label=""/>

      </LANGINFOS>

    </CMS_INPUT_TOGGLE>

    <FS_BUTTON name="st_validation_button" hidden="no" onClick="script:sc_validatepageselection">

      <LANGINFOS>

        <LANGINFO lang="*" label="Auswahl validieren"/>

      </LANGINFOS>

      <PARAMS>

        <PARAM name="form_isTranslatedAndReleased">#field.st_isTranslatedAndReleased</PARAM>

        <PARAM name="form_pageref">#field.st_pageref</PARAM>

        <PARAM name="form_pageref_hidden">#field.st_pageref_hidden</PARAM>

      </PARAMS>

    </FS_BUTTON>

  </CMS_GROUP>

</CMS_MODULE>

Regeln Absatzvorlage:

<!-- field: st_pageref, desc: ensure field is not empty -->
<RULE>

  <WITH>

  <PROPERTY name="EMPTY" source="st_pageref"/>

  </WITH>

  <DO>

  <NOT>

  <VALIDATION scope="SAVE">

  <PROPERTY name="VALID" source="st_pageref"/>

  <MESSAGE lang="*" text="Bitte wählen Sie eine Seitenreferenz aus (referenzierte Seite muss im aktuellen Sprachkanal als übersetzt markiert sein!)"/>

  </VALIDATION>

  </NOT>

  </DO>

</RULE>

   <!-- field: st_pageref, desc: validate field, selected page references page is (not) translated -->
<RULE>

<IF>

  <NOT>

  <PROPERTY name="EMPTY" source="st_pageref"/>

  </NOT>

</IF>

<WITH>

  <PROPERTY name="VALUE" source="st_isTranslatedAndReleased"/>

</WITH>

<DO>

  <VALIDATION scope="SAVE">

  <PROPERTY name="VALID" source="st_pageref"/>

  <MESSAGE lang="*" text="Die Seitenreferenz nutzt eine Seite die im Freigabestand nicht übersetzt ist, bitte korrigieren Sie Ihre Auswahl!"/>

  </VALIDATION>

</DO>

</RULE>

   <!-- field: st_pageref, desc: field and hidden shadow field selection doesn't match (user changed value), force user to validate selection -->
<RULE>

<IF>

  <OR>

  <AND>

  <NOT>

  <PROPERTY name="EMPTY" source="st_pageref"/>

  </NOT>

  <PROPERTY name="EMPTY" source="st_pageref_hidden"/>

  </AND>

  <AND>

  <NOT>

  <PROPERTY name="EMPTY" source="st_pageref"/>

  </NOT>

  <NOT>

  <PROPERTY name="EMPTY" source="st_pageref_hidden"/>

  </NOT>

  </AND>

  </OR>

</IF>

<WITH>

  <EQUAL>

  <PROPERTY name="VALUE" source="st_pageref"/>

  <PROPERTY name="VALUE" source="st_pageref_hidden"/>

  </EQUAL>

</WITH>

<DO>

  <VALIDATION scope="SAVE">

  <PROPERTY name="VALID" source="st_pageref"/>

  <MESSAGE lang="*" text="Auswahl wurde verändert, bitte validieren Sie Ihre Eingabe über die Schalfläche 'Auswahl validieren'"/>

  </VALIDATION>

</DO>

</RULE>

  </RULES>

Script sc_validatepageselection:

referencedPageIsTranslatedAndReleasedInCurrentLanguage = false;

if(!form_pageref.isEmpty() &&

  form_pageref.get().getPageRef().getPage().getReleaseStatus() != de.espirit.firstspirit.access.store.IDProvider.NEVER_RELEASED){

  referencedPageFromCurrentStore = form_pageref.get().getPageRef().getPage();

  referencedPageFromReleaseStore = context.getUserService().getStore(referencedPageFromCurrentStore.getStore().getType(), true, true).getStoreElement(referencedPageFromCurrentStore.getId());

  referencedPageIsTranslatedAndReleasedInCurrentLanguage = referencedPageFromReleaseStore.isTranslated(language);

}

form_isTranslatedAndReleased.set(referencedPageIsTranslatedAndReleasedInCurrentLanguage);

if(referencedPageIsTranslatedAndReleasedInCurrentLanguage){

  form_pageref_hidden.set(form_pageref.get());

}

Redakteure werden dann gezwungen, die getroffene Auswahl bei Veränderung über eine Schaltfläche manuell zu validieren.

Pflichtfeldprüfung:

Bildschirmfoto 2020-01-14 um 10.46.39.png

Prüfungszwang bei veränderter Auswahl:

Bildschirmfoto 2020-01-14 um 10.47.07.png

Fehlschlagende Validierung wenn die Seite der ausgewählte Seitenreferenz in der aktuellen Sprache nicht als übersetzt markiert ist:

Bildschirmfoto 2020-01-14 um 10.47.32.png

Das ganze ließe sich evtl. auch noch etwas "optimieren", insbesondere die Regeln.

Nachteil ist, dass die Validierung immer nur zum Zeitpunkt der Bearbeitung des Formulars durch den Redakteur erfolgt.

Beste Grüße, Hendrik

p.s.: entwickelt / getestet mit FirstSpirit Version 2019-12

0 Kudos

Hallo Hendrik,
danke für deine Idee, an dieser Stelle hat der Kunde dann aber doch entschieden, es ohne diesen zusätzlichen Button weiter zu machen, da dieser dennoch manuell getriggert werden müsste. Aber durchaus ein interessanter Ansatz.


VG,  Jörn

0 Kudos