Generscher Import von Dokumenten bei Migrationen

Author: arnbae
Publication Date: 8/6/2010 12:30

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

Tags: api, editorvalue, import, migration, setvaluenode, xml