Search the FirstSpirit Knowledge Base
Hallo,
folgender Auftrag besteht bei uns im Projekt:
1. Nicht frei gegebene Inhalte publizieren (FS-Skript: context.getUserService().getProject().setUseRelease(false);)
2. UX-Bridge aktivieren (Executable-class: com.espirit.moddev.uxbridge.inline.UxbInlineUtil)
3. Teilgenerierung
Benutze ich nun den Auftrag für eine nicht frei gegebene Seite (sie war bereits einmal frei gegeben, ist aber mittlerweile geändert worden), sehe ich am ContentRepository am UX-Bus folgenden Wert ankommen:
$CMS_VALUE(#global.page.releaseStatus)$ -> 0
Deaktiviere ich Schritt 2. im obigen Auftrag und schaue mir das erzeugte XML im Generierungsverzeichnis an, erhalte ich folgenden Wert:
$CMS_VALUE(#global.page.releaseStatus)$ -> 1
Benutze ich im Template eine falsche Abfrage? Oder funktioniert dies mit der UX-Bridge nicht? Wir verwenden Version 1.4.0
Mit freundlichem Gruß
Thorben Hischke
Hallo Thorben,
kannst du mal die Reihenfolge der Tasks tauschen (Position 1 mit Position 2), klappt es dann wie erwartet?
Welche FirstSpirit-Version setzt du ein?
Viele Grüße
Christoph
Hallo Christoph,
ein Tausch der Schritte 1 und 2 bringt leider nichts.
Mit freundlichem Gruß
Thorben Hischke
Ich kann es mittlerweile eingrenzen: Schritt 1 und 2 sind zu tauschen, da direkt vor der Generierung ein .setUseRelease(false) abgesetzt werden muss, ansonsten erzielt dies keine Wirkung. Somit wird also (wie gewünscht) der nicht frei gegebene Inhalt auf den UX-Bus gelegt.
Allerdings: $CMS_VALUE(#global.page.releaseStatus)$ liefert immer 0, eignet sich also nicht zur Statusübermittlung, laut API liefert diese aber den Releasestatus des Storeelements?!?
Mit freundlichem Gruß
Thorben Hischke
Hallo Thorben,
ich hab dein Problem mal nachgebaut, kann aber keinen unterschied in den Ausgaben sehen, #global.page.releaseStatus liefert in beiden Fällen 0
Meine Aufträge sind folgendermaßen aufgebaut.
UXB-Auftrag:
Normaler Generierungs-Auftrag:
Welche FirstSpirit Version setzt du ein?
Gruß
Thorsten
Hallo Thorben,
wir konnte das Problem jetzt doch nachstellen. Es scheint sich dabei um einen Bug in der UX-Bridge zu handeln.
Wir nehmen es auf unsere Fehlerliste auf. Da es sich bei der Current-Stand-Generierung aber um kein offiziell supportetes Feature handelt, hat dieser Bug nur eine geringen Priorität.
Viele Grüße
Thorsten
Hallo Thorsten,
danke für die Rückmeldung. Ich habe mir nun einen Workaround gebastelt: es sind lediglich 3 Aufträge, die dies betrifft, die erhalten bei der UX-Bridge Generierung einen entsprechenden Parameter gesetzt, den ich im Template berücksichtige, d.h. für diese 3 Aufträge setze ich den Status per default auf 'false'. (Für einen frei gegegeben Datensatz spielt dieser "falsche Zustand" für mich keine Rolle, da die nachgelagerte Applikation dies behandelt.)
Mit freundlichem Gruß
Thorben Hischke