arnbae
I'm new here

Generscher Import von Dokumenten bei Migrationen

Hallo Community,

generelle Frage nach einer Best Practice zum Thema "generischer Import". Eine spezielle Anfrage zum Thema "Import" ist inzwischen über die Übersetzungsschnittstelle gelöst, aber für Migrationen wäre es wünschenswert, beliebige Alt-Inhalte (z.B. aus anderen CMS) mit möglichst wenig Aufwand in FS ziehen zu können (primär: Seiteninhalte, nicht unbedingt Strukturen)

Deshalb die generelle Frage, ob jemand da einen besonders guten / universellen / einfachen / updatesicheren Königsweg kennt, und ansonsten einige Ideen und Anregungen von mir als Grundlage einer Diskussion (und ggf. eines Feature Requests). Eigentlich bin ich ohnehin der Meinung, das FS da eine Standard-XML-Importschnittstelle anbieten sollte.

Berg und Prophet

Meine erste Überlegung ist, an welcher Stelle man die Schnittstelle ansetzt - FS-seitig, oder beim Altsystem. Vielversprechender ist für mich der Import über ein generisches Import-Format (XML?), welches die möglichen Datenstrukturen in FS genau abbildet. Aus dem Altsystem müssen dann die Daten entsprechend exportiert und aufbereitet werden, aber in Endeffekt scheint mir das der generellere Weg, um den Import wiederzuverwenden.

Zwischenfrage: Gibt es da schon, und ich bin nur blind, und sehe das offensichliche nicht?

Mögliche Importformate

Meine zweite Überlegung ist, XML-Formate zu verwenden, die möglichst nahe an FS-Funktionalitäten / -Strukturen angelehnt sind, um Transferaufwände zu vermeiden. Folgende fallen mir da ein, wobei alle Formate nicht dokumentiert sind, was eigentlich e-spirit in die Pflicht nimmt.

  • Rechtsklick => Exportieren-Format (Zip): Das ZIP-Format lässt sich bereits jetzt von Hand oder per API importieren, kann mehrere Dokumente und Strukturen enthalten. Das Format ist aber komplex, weil auch mehreren Teilen/Dateien bestehend.

  • Export der Übersetzungs-API-Funktion: Nicht sehr vielversprechend aus zwei Gründen:
    1. Links werden in einem Hex/Binärformat codiert (Blackbox)
    2. Re-Import füllt immer die Felder bestehender Dokumente, also ungeeignet für eine Erstmigration

  • EditorValue.toXml()-Format: Diese Methode erzeugt ein DOM-XML-Format für alle Feldarten in FS, leider scheint aber die entsprechende fromXml()-Methode zu fehlen, oder sie ist zumindest nicht dokumentiert. Bei einem DOM-Editor wird beispielweise folgende Struktur zurckgeliefert, die sich recht einfach aus Altsystemen erzeugen ließe:
    <LANG id="DE" set="1"><DOM><p>This is DOM Text <CMS_LINK linktemplate="linkconf00" type="genericLink"><TEMPLATECONTENT><CMS_VALUE name="lt_text_2"><LANG id="§" set="0"/></CMS_VALUE><CMS_VALUE name="lt_text_1"><LANG id="§" set="1"><TEXT>more</TEXT></LANG>

    Eine ensprechende Methode gibt es auch für StoreElements

Die Anlehnung an bestehende FS-Formate geschieht natürlich aus der Hoffnung, die Inhalte sehr generisch in FS bringen zu können, und möglichst wenig auf die Eigenarten und unterschiedlichen API-Methoden der einzelnen Feld-Editoren eingehen zu müssen. Beispiel: Es ist einfacher, ein XML-Konstrukt in einem Rutsch in einen Link-Editor zu schreiben, statt alle möglichen Felder und Attribute aus einem Quellformat zu extrahieren und einzeln schreiben zu müssen.

Zentrale Frage: wo liegt die höchste Abstraktionsebene, bei der man in der API mit dem Import anfangen kann?

In FS 3.1 hatten wir bereits einmal so einen Import auf der Basis von EditorValue.set(Language language, T object) geschrieben, wobei "object" ein DOM-Objekt war, aber das scheint so nicht mehr zu gehen. Eine Hoffnung wäre auch setValueNode, aber die Doku ist nicht so prickelnd (wie vieles in der API-Doku :smileycry:):

setValueNode

void setValueNode(Element dataXml)
Set values of editor by dataXml element. This method may be called more than once.

Parameters:
dataXml - DataXML object containing values
Since:
3.0.121
5 Replies
boesebeck
Crownpeak employee

Hallo Herr Bär,

Arndt Bär schrieb:

Deshalb die generelle Frage, ob jemand da einen besonders guten / universellen / einfachen / updatesicheren Königsweg kennt, und ansonsten einige Ideen und Anregungen von mir als Grundlage einer Diskussion (und ggf. eines Feature Requests). Eigentlich bin ich ohnehin der Meinung, das FS da eine Standard-XML-Importschnittstelle anbieten sollte.


Berg und Prophet


Meine erste Überlegung ist, an welcher Stelle man die Schnittstelle ansetzt - FS-seitig, oder beim Altsystem. Vielversprechender ist für mich der Import über ein generisches Import-Format (XML?), welches die möglichen Datenstrukturen in FS genau abbildet. Aus dem Altsystem müssen dann die Daten entsprechend exportiert und aufbereitet werden, aber in Endeffekt scheint mir das der generellere Weg, um den Import wiederzuverwenden.



Zwischenfrage: Gibt es da schon, und ich bin nur blind, und sehe das offensichliche nicht?

Leider gibt es noch kein generisches Format was für einen Import genutzt werden kann, daher müssten Sie ein Feature Request erstellen. (Auf das Format gehe ich nochmal später ein)

Bisher wurden die Importer projektspezifisch erstellt, da eine transformation in ein generisches Format nicht immer möglich ist, bzw die Transformation des Fremdformat in das generische Format genau so aufwendig wär, wie ein Importer der das Fremdformat lesen kann.

  • Rechtsklick => Exportieren-Format (Zip): Das ZIP-Format lässt sich bereits jetzt von Hand oder per API importieren, kann mehrere Dokumente und Strukturen enthalten. Das Format ist aber komplex, weil auch mehreren Teilen/Dateien bestehend

Das Format halte ich nicht für die beste Lösung, da das Format zu FirstSpirit technisch ist und wie Sie schon festgestellt haben .... etwas zerpflückt ist.

  • Export der Übersetzungs-API-Funktion: Nicht sehr vielversprechend aus zwei Gründen:
    1. Links werden in einem Hex/Binärformat codiert (Blackbox)
    2. Re-Import füllt immer die Felder bestehender Dokumente, also ungeeignet für eine Erstmigration

Das Format halte ich für sehr geeignet, es müsste nur erweitertet werden

  • Links müssten in einem anderen Format gehalten werden
  • Anlage von Strukturen, nicht nur das Aktualisieren
  • Eine interne Mapping-Tabelle für interne Links Fremd-UID => FirstSpirit-UID (Diese Tabelle müsste bei einem erneuten Teilimport berücksichtig werden)

Hier mal ein Beispiel aus dem Mithras Projekt

<?xml version="1.0"     encoding="UTF-8"?>
<!DOCTYPE FIRSTspirit_XML_EXPORT SYSTEM "TranslationXml.dtd">
<FIRSTspirit_XML_EXPORT resource_language="DE" version="4.2.219">
<PAGENODE id="97813" name="firstspirit_2" revision="16858">
<PAGE id="97815" name="umsetzungmitfirstspirit" revision="16361">
<CMS_VALUE name="pt_headline">FirstSpirit</CMS_VALUE>
<CMS_VALUE name="pt_subheadline">Das Rückgrat Ihrer digitalen Unternehmenskommunikation</CMS_VALUE>
<CMS_VALUE name="pt_intro"><FORMAT name="p">J...icht wird.</FORMAT></CMS_VALUE>
<BODY id="Content center" name="Content center">
<SECTION id="97817" name="textbild" templateid="96073">
<CMS_VALUE name="st_text"><FORMAT name="p">Firs..lte.</FORMAT><FORMAT name="p"/><FORMAT name="p"><FORMAT name="b">Umsetzung auf Basis eines CMS</FORMAT></FORMAT><FORMAT name="p">Be..statt:</FORMAT><FORMAT name="p"><FORMAT name="ul" style="0"><FORMAT name="li">En..esigns</FORMAT><FORMAT name="li">Umsetzung des Frontends, also der darzustellenden Website</FORMAT><FORMAT name="li">Implementierung des Backends, also des Redaktionssystems</FORMAT><FORMAT name="li">Eingabe / Import von Inhalten</FORMAT><FORMAT name="li">Die tägliche Arbeit mit dem System</FORMAT></FORMAT></FORMAT><FORMAT name="p"/></CMS_VALUE>
</SECTION>
<SECTION id="97819" name="textbild_2" templateid="96073">
<CMS_VALUE name="st_headline">Frontend-Entwicklung</CMS_VALUE>
<CMS_VALUE name="st_text"><FORMAT name="p">Nachdem im Design die H..gationselementen.</FORMAT></CMS_VALUE>
</SECTION>
</BODY>
<BODY id="Content right" name="Content right">
<SECTION id="97825" name="textbildmarginalteaser" templateid="96034">
<CMS_VALUE name="st_headline">Kontakt</CMS_VALUE>
<CMS_VALUE name="st_text"><FORMAT name="teaserboxtext">Möchten Sie mehr über FirstSpirit erfahren?</FORMAT><FORMAT name="teaserboxtext">Tel:     +49 231.286 61-30</FORMAT><FORMAT name="teaserboxtext">Fax: +49 231.286 61-59</FORMAT><FORMAT name="teaserboxtext">Mail:  info@e-Spirit.de </FORMAT><FORMAT name="teaserboxtext">Wir freuen uns auf Ihre Kontaktaufnahme! </FORMAT></CMS_VALUE>
</SECTION>
</BODY>
</PAGE>
</PAGENODE>
</FIRSTspirit_XML_EXPORT>

Siehe auch den Anhang.


  • EditorValue.toXml()-Format: Diese Methode erzeugt ein DOM-XML-Format für alle Feldarten in FS, leider scheint aber die entsprechende fromXml()-Methode zu fehlen, oder sie ist zumindest nicht dokumentiert. Bei einem DOM-Editor wird beispielweise folgende Struktur zurckgeliefert, die sich recht einfach aus Altsystemen erzeugen ließe:
    <LANG id="DE" set="1"><DOM><p>This is DOM Text <CMS_LINK linktemplate="linkconf00" type="genericLink"><TEMPLATECONTENT><CMS_VALUE name="lt_text_2"><LANG id="§" set="0"/></CMS_VALUE><CMS_VALUE name="lt_text_1"><LANG id="§" set="1"><TEXT>more</TEXT></LANG>

    Eine ensprechende Methode gibt es auch für StoreElements

Die Anlehnung an bestehende FS-Formate geschieht natürlich aus der Hoffnung, die Inhalte sehr generisch in FS bringen zu können, und möglichst wenig auf die Eigenarten und unterschiedlichen API-Methoden der einzelnen Feld-Editoren eingehen zu müssen. Beispiel: Es ist einfacher, ein XML-Konstrukt in einem Rutsch in einen Link-Editor zu schreiben, statt alle möglichen Felder und Attribute aus einem Quellformat zu extrahieren und einzeln schreiben zu müssen.

Wie Sie schon sagen sind diese Formate zu sehr an FirstSpirit gebunden, Es besteht auch hier die Gefahr, das die interne Datenhaltung sich mal ändert und das Format nicht mehr gelesen werden kann.

Wenn Sie aktuell einen Importer erstellen wollen, sollten Sie über die API Funktionen der einzelnen Editoren gehen. Hier mal ein Beispiel für die Anlage einer Seite und einem einfachen TextEditorValue.

...
Template pageTemplate = ((TemplateStoreRoot) getUserService().getStore(Type.TEMPLATESTORE, false)).getPageTemplates().getTemplate(_template);
_page = parentFolder.createPage("MeinNeuePage", pageTemplate, true);
...
try {
     _page.setLock(true, true);
     Body body = _page.getBodyByName(_body);    
     _section = body.createSection(name, _section_template);
     ...
     Data _data = _section.getData();
     DataValue dataValue = _data.get(_var);
     EditorValue<TextEditorValue> editorValue = dataValue.getEditor();
     editorValue.set(language, _text);
     ...
     _section.setData(_data);
     ...
     _page.save("Comment", true);
} catch (Exception e) {
     //Do something
} finally {
     _page.setLock(false, true);
}
...

Weitere Editoren Beispiele können Sie hier entnehmen.

Vielen Dank für eine klare Aussage und Richtung. Sehe ich das richtig, dass <TextEditorValue> so ziemlich das einfachste Beispiel von allen Feldarten ist? Smiley Wink Ich fürchte eher den Aufwand bei Links, DOMs, DOMtables etc. Dann wird man bei der nächsten Migration zunächst wohl nicht an einem aufwändigen Überführen in die Zieleditoren vorbeikommen.

Die Aussage "Datenformat wird inkompatibel, wenn sich mal die interne Datenhaltung ändert" kann ich grundsätzlich nachvollziehen, wäre in meinen Augen aber nicht gravierend. Für mich geht es weniger um die Archivierung als vielmehr um den zeitnahen Datenaustausch und - besonders bei Migrationen - den Import. Da kann ich die Releasestände von FS durchaus beeinflussen.

Ich stimme voll und ganz zu, dass ein modifiziertes Translation-Format am sinnvollsten wäre, weil ich mir vorstellen könnte, dass man das auch recht leicht abwärtskompatibel halten kann.

Schöne Grüße,

Arndt Bär

0 Kudos
boesebeck
Crownpeak employee

Hi,

Vielen Dank für eine klare Aussage und Richtung. Sehe ich das richtig, dass <TextEditorValue> so ziemlich das einfachste Beispiel von allen Feldarten ist? Smiley Wink Ich fürchte eher den Aufwand bei Links, DOMs, DOMtables etc. Dann wird man bei der nächsten Migration zunächst wohl nicht an einem aufwändigen Überführen in die Zieleditoren vorbeikommen.

TextEditorValue ist neben Number der einfachste Editor, zu Dom und DomTable ist aber ebefalls ein Example zu finden. Dom und DomTable sind gerade die Knackpunkte bei eine Migrations von einem Fremdsystem. Da in FS jedes Element, bis zur Tabelle oder Font Style, über Templates definierbar ist, ist das genau der hakelige Teil einer Migration. Leider hört die Trennung von Inhalten und Design bei den meisten System hier auf und man muss dummes HTML migrieren.

Die Aussage "Datenformat wird inkompatibel, wenn sich mal die interne Datenhaltung ändert" kann ich grundsätzlich nachvollziehen, wäre in meinen Augen aber nicht gravierend. Für mich geht es weniger um die Archivierung als vielmehr um den zeitnahen Datenaustausch und - besonders bei Migrationen - den Import. Da kann ich die Releasestände von FS durchaus beeinflussen.

Meinen Sie den Austausch zwischen zwei FS Projekten/Server, oder einem Fremdsystem und FS?

Gruß,

Gerrit Bösebeck

0 Kudos

Meinen Sie den Austausch zwischen zwei FS Projekten/Server, oder einem Fremdsystem und FS?

Eigentlich beides, aber vor allem die Migration aus einem Fremdsystem. Das ist ja meist zeitlich begrenzt, also könnte ich ohne weiteres damit leben, dass sich das generische Zielformat vielleicht bei der nächsten Migrationsaktion in Teilen geändert hat.

Ein generisches Zwischenformat, bei dem E-Spirit die eine Hälfte der Entwicklung (und eine gewisse Normierung) übernimmt, wäre mir allemal lieber, als dass ich den ganzen Weg vom Altsystem bis hin zur API gehen muss. Die Chance, die ich dabei sehe: Diese Lösung wird von verschiedenen Partnern zig-Mal separat programmiert werden, wenn auch immer eine Altdaten-Übernahme ansteht. Mit einem universellen, FS-nahen Zwischenformat würde der Migrationsaufwand deutlich reduziert, und man könnte das FS wesentlich preiswerter in Migrationsprojekten anbieten.

0 Kudos
boesebeck
Crownpeak employee

Arndt Bär schrieb:

Ein generisches Zwischenformat, bei dem E-Spirit die eine Hälfte der Entwicklung (und eine gewisse Normierung) übernimmt, wäre mir allemal lieber, als dass ich den ganzen Weg vom Altsystem bis hin zur API gehen muss. Die Chance, die ich dabei sehe: Diese Lösung wird von verschiedenen Partnern zig-Mal separat programmiert werden, wenn auch immer eine Altdaten-Übernahme ansteht. Mit einem universellen, FS-nahen Zwischenformat würde der Migrationsaufwand deutlich reduziert, und man könnte das FS wesentlich preiswerter in Migrationsprojekten anbieten.

Ja - dies würde bei einer Migration hilfreich sein, können Sie dazu ein FR erstellen. Die Definition bzw Anforderung an das Format können wir ja unter dem FR weiterführen.

Gruß

Gerrit Bösebeck

0 Kudos