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.
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.