hjaeger
Elite Observer

Content-Export in JSON: handgebastelt oder generisch? best practices?

Hallo zusammen.

Wir abstrahieren gerade die CMS-Inhalte in einem strikt generischen Ansatz auf Template-Ebene, da es meines Wissens nach hierfür keine out-of-the-box-Lösung für firstSpirit gibt.

Das statische auscodieren diverser Templates erschien mir nicht skalierbar.

Wie spielt Ihr in vergangenen oder aktuellen Projekten eure Inhalte bspw. in CaaS oder andere Content-Repos aus? evtl. projekt-spezifische FS-Module?

Bin mal gespannt was da so kommt, vielleicht kann man sich da austauschen.

Viele Grüße

7 Replies
bIT_sosswald
Returning Responder

Hallo Hagen,

für CaaS würde ich tatsächlich die Templates entsprechend auscodieren, da man dort ja vermutlich eine ganz bestimmte Datenstruktur haben will. Evtl. will man ja auch nicht alle Daten aus den Templates ausspielen etc.

Wenn es darum geht ALLE Daten, die der Redakteur in Eingabeformularen gepflegt hat, auszuspielen, würde ich über die API und ein Modul gehen.

Du kannst über die API für jedes Seite die Formulardaten (inkl. Metadaten etc.) abfragen, dort dann über alle Elemente iterieren. (Man muss sicherstellen, dass auch rekursiv alle Elemente mitgenommen werden, z.B. Absätze, verschachtelte FS_CATALOG Elemente, etc.) Das wird irgendwann etwas komplexer, da man alle möglichen Eingabekomponenten erkennen und teilweise individuell behandeln muss.

Die so ermittelten Daten könnten dann z.B. in einer Baumstruktur in JSON abgelegt werden etc.

Das sollte auf jeden Fall funktionieren. Habe das vor Jahren mal für eine Volltextindexierung gemacht.

Grüße

Sandro

0 Kudos

Hallo zusammen,

alternativ lässt sich innerhalb des Ausgabekanals die JSON-Struktur innerhalb von Maps abbilden und anschließend mit toJSON (siehe Online Dokumentation FirstSpirit - Datentyp Map ) ausgeben.

Das erspart zumindest das schreiben der ganzen Klammern und sonstigen Syntax-Zeichen von JSON.

Das Zusammenstellen des JSON via Modul ist zwar genererischer und benötigt weniger SourceCode, ist jedoch a) nicht FS-Standard und b) könnten dadurch ausversehen Daten rausgeschrieben werden, die ggf. nicht veröffentlicht werden sollten (wenn die von Sandro berschriebenen "individuell"-Fälle vergessen würden).

Gruß,

Christopher

0 Kudos
jan_bogutzki
I'm new here

Hallo Hagen,

wir haben uns die Frage ebenfalls gestellt gehabt, als wir auf reine JSON-Ausgabe umgestellt haben. Unser Code ist komplett handgeschrieben.

Gründe:

- Objekthierarchien können sauber und besser abgebildet werden, erfordert aber auch eine gewisse Disziplin

- Zusätzliche Datenquellen (Datenbank, Report usw.) können so eingebunden werden, dass nur die nötigen Daten enthalten sind (insb. für Vorschauelemente)

- nicht seitenspezifische Inhalte, wie zum Beispiel Menüstrukturen können hinzugefügt werden

Mit Formatvorlagen haben wir auch einzelne Strukturen standardisiert. Innerhalb dieser werden dann teilweise unterschiedliche Datenfelder sauber in die richtige Exportstruktur gewandelt.

Gruß

Jan

hjaeger
Elite Observer

Hallo und danke für die Rückmeldungen.

Es ist ja ein bisschen von allem dabei. Ich verarbeite aktuell alle Daten in einem FS-Ausgabekanal auf formdata-Ebene und wandere Verschachtelungen in Bodies, FS_Lists, Catalogues, etc. rekursiv durch. Knifflig wurde die Abbildung der DOM(-Table)-Editoren, da dort ggf. genestete Linktemplates aufgelöst werden mussten. Aber das war mit einem selbstgebauten Stack auch machbar und funktioniert mit n Verschachtelungsebenen noch ohne StackOverflow-Error. Metadaten, GCAs, Datenquellen etc. sind auch implementiert. Das Feature, ggf. best. Eingabe-Komponenten explizit nicht mit auszuspielen, ist uns noch nicht untergekommen. Das sollte sich aber mit einer Blacklist realsieren lassen, falls erforderlich.

Alles in allem läuft es wohl bei allen Dienstleistern/Integratoren auf projektspezifische Lösungen hinaus. Auch wenn man das CMS quasi nur noch headless betreibt und ein Teil der Funktionalität abgeschnitten wird, fände ich eine herstellerseite Lösung hier ganz praktikabel. Bei vielen (E-/W-)CMS gibt es eine derartige Schnittstelle ja meist out-of-the-box (bspw. Jahia, hippo (jetzt  bloomreach, onehippo), gibt sicherlich noch ne Menge mehr.

viele Grüße

Hagen

Hallo Hagen,

ja, der Part mit dem Ausblenden ist auch kompliziert 🙂

Wir haben bei uns im System einige Select/Radio-Button Listen, wo der Redakteur sich zwischen Darstellungsvarianten entscheiden kann. Diese führen daher auch dazu, dass bestimmte Elemente aus dem Formular nicht exportiert werden oder eventuell anders formatiert ausgegeben werden. Daher ist der manuelle Ansatz schon der flexiblere. Vermutlich wird das auch die große Schwierigkeit für eine generelle Lösung aus dem CMS selbst heraus.

Gruß

Jan

0 Kudos
bIT_sosswald
Returning Responder

Hallo Hagen,

schau dir mal die Releasenotes von der Version 2019-12 an, ab dieser Version gibt es eine OutOfTheBox Funktion zum Erzeugen von JSON Strukturen ganzer Seiten.

[RELEASE] FirstSpirit™ 2019-12 released

Grüße

Sandro

Hallo Sandro.

Vielen Dank für den ping dazu.

VG

0 Kudos