Tim Adler

Häufig sucht man sich sein CMS ja irgendwie nicht aus, sondern man wird ausgesucht: "Ich hab da gehört es gibt XY, können wir das nicht damit machen?" - Auch sonst ist die Wahl eines CMS-Systems bzw. Framework irgendwie was trendabhängiges: Als man vor Jahren noch stolz die Brust schwellte, wenn man überhaupt seine Webseite über ein Backend pflegen konnte, hält sich der gemeine Webdesigner heutzutage für besonders trendtreu, wenn er bei den Worten "Ruby on Rails" wissend nicken kann.

Und eigentlich ist dieser Beitrag jetzt gar keine Liebeserklärung an ein bestimmtes System, sondern viel mehr an ein Prinzip. Denn, hat man es nicht irgendwie im kleinen Codierfinger, dass man das Falsche tut, wenn man dem User das Pflegen von "Seiten" (Typo3) zumutet?

Was ist denn so schlimm daran, wenn man "Seiten" pflegt?
Nun, offensichtlich natürlich erstmal gar nichts. Sonst würde ja nicht so viele Systeme darauf basieren Inhalte nach diesem Prinzip anzunehmen. Das Denkschema "Seite" ist allerdings eines, das nicht tatsächlich auf den einzustellenden Inhalten beruht: Vielmehr schreibt das Prinzip Webseite eine solche Art und Weise der Präsentation vor und zwingt damit den Inhalt in eine eigentlich ziemlich unnatürliche Form.

Auch der Benutzer hat mit den "Seiten" so seine Probleme: Sein Ziel ist es zum Beispiel einer Seite eine bestimmte Kontaktadresse hinzuzufügen. Er muss sich also den Seitenbaum entlang hangeln genau zu der Seite, wo die Adresse hinterlegt ist. Hier angekommen wird gepflegt. Was aber, wenn er die Kontaktadresse anders eingibt, als bei anderen Kontaktadressen? Was, wenn die Adresse mehrfach auftaucht, auf den Seiten. Dann wird es inkonsistent und er muss doppelt pflegen.

Als letzte der betroffenen Spezies nehmen wir jetzt mal noch den Designer: Der hat sich für die verschiedenen Seitentypen ein ganz bestimmtes Layout ausgedacht, in dem präsentiert werden soll. Überlässt man es jetzt allerdings dem User, wie genau die Seiten gestaltet werden sollen, dann wird spätestens die n+1ste Person sich nicht mehr an den Style-Guide halten und somit das schöne Layout zerlegen...und nichts fällt mehr auf, als die Stelle, die aus dem Layout fällt.

Aber genug der Nörgelei... 

Wie könnte man es besser machen?
Irgendein weiser Man erfand in grauer Vorzeit beim Termitenstochern die Objektorientierung und stellte fest, dass sie zu allerhand zu gebrauchen war. Unter anderem zum Modellieren, Gestalten und Entwickeln von sehr coolen Webseiten. Was ist überhaupt gemeint?
Nun die Idee ist eigentlich ganz simpel: Das CMS sollte keine "Seiten" oder "Beiträge" als vorgegebene Inhaltscontainer im Backend bieten, sondern vielmehr entsprechend den, auf der Seite präsentierten, Contents passende Eingabgemöglichkeiten. Für diesen Blog zum Beispiel: "Beiträge", "Kommentare", "Menupunkte", "Projekte" und "Randnotizen". Das bietet so einige Vorteile:

• Der Benutzer findet im Backend genau solche Inhaltselemente, die er auch pflegen will. D.h. Adressen lassen sich auch als "Adressen" pflegen und einfach per Verknüpfung an alle benötigten Stellen verlinken.
• Ein festverdrahtetes Design sorgt für eine konsistent Gestaltung der Webseite, ohne das einzelne Seite aus dem vorgegebenen Style-Guide ausscheren könnten.
• Der Content ist beliebig weiterverwertbar: Denn durch die Formalierung zu echten Objekten und einer klaren Tabellenstrukturierung, kann man die von den Benutzern eingegebenen Daten auch beliebige weiterverarbeiten und aggregieren.
• Bei der Festlegung von Anforderungen für eine Webseite können so ganz klare Richtlinien für eine Webseite geschaffen werden: So legt man einmal fest, was gepflegt werden können soll und kommt so zu einem klaren Schema, dass als UML-Diagramm locker auch pflichtenhefttauglich ist.

Im Optimalfall muss man sich bei der Entwicklung eines solchen objektorientierten Systems nicht mal mehr um die Entwicklung eines Backends kümmern. Das sollte das System möglichst selbst erstellen und man muss es nur noch entsprechen konfigurieren.

Jetzt mal Tinte auf den Füller, welches System kann sowas überhaupt?
 NameEigenschaften
Umgebung  Django

• Automatisches Adminbackend
• Umfangreiches Framework mit zahlreichen Features
• Sehr schnelle Entwicklung (Weblog in 5 Minuten)
• Eigene Template-Sprache mit coolen Vererbungsfunktionen
• Super Dokumentation

Weiterhin kann man wohl auch die weithin bekannt Frameworks Ruby on Rails und CakePHP dazuzählen. Die bieten mit eigenen Datenbankzugriffs-APIs und einer entsprechenden MVC-Struktur, das Grundgerüst für das, was objektorientiertes Content-Management ausmacht.

Was eindeutig nicht dazuzählt sind solche Code-Haufen wie Typo3 und Joomla (absichtlich kein Link) oder aber Drupal, Wordpress. Die bieten gerade eben entweder nur das Pflegen von ganz bestimmten, nicht frei wählbaren Inhaltstypen, oder aber sind komplett auf Seiten fixiert. 

Wer gerne noch weiterlesen möchte, der guckt bei thinkvitamin.com unter "Redefining Content Management".