Hallo allerseits,
ich bin gerade dabei mir ein bisschen über CMS Gedanken zu machen. Ich hab z.Z. zwar nicht vor eines zu programmieren, aber denke darüber nach, wie die Daten gespeichert und möglichst einfach zu bearbeiten wären.

Meine Idee ist folgende:
Es gibt verschiedene "Contenttypen". Beispielsweise Artikel, Bilder, Newseintrag, etc. Dabei müssen für jeden Contenttyp verschiedene Daten gespeichert werden.
Für den Artikel müssen nur zwei Strings gespeichert werden: Titel und Text (evtl. HTML formatiert).
Für die Bilder soll ein Titel und eine (variable) Liste von Bildern gespeichert werden (evtl. mit zugehörigen Bildunterschriften).
Für den Newseintrag soll ein Titel, der Text, ein Datum, der Autor und evtl. eine Liste von Links gespeichert werden.

Um nun nicht für jeden Contenttyp eine neue Tabelle in der Datenbank anzulegen, dachte ich mir, es wäre u.U. sinnvoll, die Daten als XML in der DB zu speichern (eine (Volltext) Suche soll erstmal ignoriert werden).

Jetzt kommt der Knackpunkt: Um das ganze möglichst erweiterbar (neue Contenttypen) zu machen, soll die Struktur der Daten (in XML) beschrieben werden, um daraus ein Formular zu generieren und die Daten dann (XML) in der DB zu speichern.

Also:
a) Datenstruktur --> Formular --> Daten --> Datenbank (Datensatz anlegen)
b) Datenbank --> Daten -(Datenstruktur)-> Formular (zum bearbeiten der Daten) --> Daten --> Datenbank (Datensatz bearbeiten)
und (hier irrelevant):
c) Datenbank --> Daten --> Parser --> HTML Ausgabe (Datensatz ausgeben)

Ein Contenttyp würde dann also mit einer Datenstruktur und einem Parser (+evtl. Template) kommen. Der Parser interessiert mich an dieser Stelle nicht. Meine Überlegungen drehen sich um die Datenstruktur.

Ich hoffe meine Idee kommt soweit gut rüber. Was ich nun Suche sind Anregungen, wie ich die Datenstruktur beschreiben könnte. Meine bisherigen Versuche würden zwar für den Artikel passen, aber bei den Listen (variabler Länge) hapert's dann.
Gibt es zu diesem Thema evtl. gute Literatur? Google bringt mir eher wenig.

sincères amitiés scus
--
Tand, Tand ist das Gebilde von Menschenhand

Bezueglich der Erweiterbarkeit: Meiner Meinung nach sattelst du das Pferd von der falschen Seite auf. Wieso nimmst du dir die Möglichkeiten und Vorteile einer Datenbank wie zum Beispiel die Validierung der Daten oder die Durchsuchbarkeit selber weg, indem du XML Container speichern willst? Wenn du nicht selber die Tabellen erstellen moechtest wieso überlässt du diese Aufgabe dann nicht dem Objektrelationales Mapping? Propel sollte das leisten was du suchst. Man beschreibt die Objekte, die benötigt werden in XML und bekommt die entsprechenden SQL Tabellenstatements auf der einen und Datenobjekte und die dazugehörigen Farbriken auf der anderen Seite raus.

Datenbank <-> Objektrelationales Mapping <-> Applikationslogik (bevorzugt OO)

Natürlich ist Propel für soetwas nicht zwingend nötig. Alternativ kannst du dir auch selber etwas mit den PDO Funktionen und dem PDO::FETCH_OBJ Modus zusammenbasteln.

Das XML würde ich aber nicht komplett entfernen. Es eignet sich nämlich optimal in Kombination mit XSLT dazu den Punkt c abzuarbeiten. Die Datenobjekte werden in ein XML Dokument umgewandelt, welches die aktuell darzustellende Seite beschreibt.

Datenobjekte (erstellt durch ORM und/oder die Applikationslogik) -> XML -> XSLT -> HTML

There is nothing wrong with high standards. It's your problem that you don't meet them.
If you think it's simple, then you have misunderstood the problem.
When a customer says "nothing has changed", assume they're lying.

Hmm, ich werd' mir mal Propel genauer anschauen. Das hört sich erstmal ganz vielversprechend an.
Für weitere Vorschläge bin ich aber immernoch dankbar.

sincères amitiés scus
--
Tand, Tand ist das Gebilde von Menschenhand