MosXML Konzepte

MosXML Alpha 1.1 ist eine XML-basierte Variante des CMS Mambo. Da es bislang sehr wenig Dokumentation gibt, mag hilfreich sein, was ich über die Konzepte dieses CMS herausfinden konnte.

Nur bei Komponenten, die keine feinstgranulare Eingabe der Inhalte in Formularfelder erwarten, sondern eine Formatierung mit Auszeichnungen, ist es notwendig, XML in die Datenbank zu schreiben und das MosXML Template entsprechend zu gestalten. Bei allen anderen Komponenten und Modulen ist die PHP-Logik dafür zuständig, die einzelnen Inhalte der (Nur-Text-)Datenbankfelder zu XML zusammenzusetzen. Ggf. sind also Erweiterungen von Komponenten nötig. Die Contact-Komponente wurde bereits für MosXML angepasst; sie gibt z.B. folgendes XML-Dokument aus

<contact-details>
  <address line="1">[...]</address>
  <address line="2">[...]</address>
  [...]
  <phone>[...]</phone>
  <misc>[...]</misc>
</contact-details>
<contact-form>[...]</contact-form>

Nur die Inhalte der Tags stehen in der Datenbank, die Tags selbst werden durch PHP-Code in der Komponente hinzugefügt. Diese Tags werden im Template primary.xsl verarbeitet. Das zeigt, wie eigene Tags definiert werden können: indem man sie einfach verwendet und ihre Verarbeitung in das XSL-Template aufnimmt. Man benötigt nicht für jede Komponente eine eigenes XML Schema o.ä., sondern nur die fertig generierte XML-Seite mit den Beiträgen aller Komponenten und Module braucht eine Definition des Gesamt-Schemas. Dieses erweitert sich jeweils, wenn eine neue Komponente neue Tags einführt.

Die Unabhängigkeit von Inhalt und Darstellung ist gewährleistet, wenn für die Inhalte (hier: der Komponente Content) ein, evtl. eigenes, XML Schema existiert, das nicht mehr geändert werden muss, um andere Darstellungen zu ermöglichen. Dazu muss es semantisch auf möglichst hogem Niveau sein, um damit alle auch später auftretenden Aufgabenstellungen lösen zu können. Beispiel: es muss die semantische Information enthalten sein, welche Abschnitte Quelltext in welcher Sprache darstellen. Eine Erweiterung wie jetzt der Mambo moscode hat es dann nicht mehr nötig, dazu eigene Tags einzuführen.

Die Trennung von Inhalt und Darstellung bedeutet nicht, dass sich das Schema der von MosXML generierten XML-Dateien überhaupt nicht mehr ändern dürfte. Für völlig neue Inhaltstypen oder neue Komponenten mit neuer Semantik sind möglicherweise Erweiterungen nötig. Es sind keine Erweiterungen aufgrund von geänderten Anforderungen der Darstellung, sie sind deshalb zulässig.

Alle Module und Komponenten sollen in MosXML ausschließlich XML ausgeben – sie sind damit völlig unabhängig von der Darstellungsschicht, denn sie wissen nicht, in welche Ausgabeformate dieser XML-Code dann weiterverarbeitet wird. Dass die Darstellungsschicht die ausgegebenen XML-Tags kennen muss und damit von den gerade verwendeten Mambo-Elementen abhängig ist, ist anscheinend unvermeidlich. Und nicht tragisch: das Spezielle ist jetztvom Allgemeinen abhängig.

Die Darstellungsschicht kann und soll ja geändert werden, nur nicht die anderen Schichten.

Die XML-Datei, wie man sie auch über den Link »View Page XML« auf
jeder generierten HTML-Seite erreichen kann, stellt den absoluten Endpunkt aller Aktionen der Verarbeitungsschicht dar. Auch alle Mambots wurden schon angewandt. Das zeigt sich daran, dass {mosimage}-Tags bereits in <img />-Tags mit vollständigen URLs konvertiert wurden. Vgl. dazu das Content Item »Welcome to the MOSXML Alpha Install« und den dafür generierten HTML-Code. Die XML-Datei enthält also alle benötigten Informationen und die XSL-Datei alle benötigte Logik, um die Darstellungen zu erzeugen. Mambots, Komponenten und Module werden jetzt nicht mehr benötigt – sie gehören zu den unteren Schichten. Das bedeutet z.B. auch: bei Verzicht auf den {mosimage}-Mambot hat die Komponente »Content«, nicht der XSL-Stylesheet, die Aufgabe, relative URLs zu Bildern in absolute URLs zu wandeln, die vom MediaManager behandelt werden. Alternativ könnten Mambots einfach die Aufgabe bekommen, XML-Tags in andere XML-Tags umzuwandeln und dürften nicht mehr eigene Tags wie {mosimage} einführen, weil dies die Schichtenarchitektur zerstört.


Posted

in

,

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.