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?
| Name | Eigenschaften
| Umgebung |
|---|
| Django | - Automatisches Adminbackend
- Umfangreiches Framework mit zahlreichen Features
- Sehr schnelle Entwicklung (Weblog in 5 Minuten)
- Eigene Template-Sprache mit coolen Vererbungsfunktionen
- Super Dokumentation
| Python, Apache, MySQL (o. Postgresql)
|
Riot V6
| - Extrem cooles Design
- Sehr durchdachte Systemarchitektur
- Automatisch Administrationsbackend
- Insbesondere für die Applikationsentwicklung geeignet
- Sehr vielseitig, es gibt kaum etwas, was man nicht machen kann
| Java, JSP, Tomcat, XML, Spring, Hibernate u.a.
|
Expression Engine
| - Eigentlich ein Blogging-System
- Frei wählbare sog. "Weblog", die sich wie Klassendefinitionen verhalten
- Automatisches Admin-Backend
- Kommt bereits mit einigen Templates
- Läuft auf fast jedem Webserver
| Apache, PHP, MySQL
|
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".
Comments
Etwas webphilosophisch angehauchter Text.. Sehr schön, weiter so..!!
Hallo,
diese objektorientierte Herangehensweise klingt ja sehr interessant, allerdings verstehe ich nicht so ganz warum Du Drupal da ausschließt. Spätestens seit Version 5 ist das Anlegen von frei definierbaren Inhaltstypen Teil der Core-Funktionalität. Auch in der 4er-Version war das schon möglich, mit den Modulen "Content Construction Kit" und "Views".
Mmh, für den Fall natürlich Asche auf mein Haupt :)!
Also ich das letzte Mal Drupal getestet habe, da kam es mir vor, wie das übliche CMS mit Seiten+Kategorien. Ich muss aber gestehen, beim ersten Eindruck ist es erstmal geblieben.
Ich persönlich lege immer viel Wert darauf, dass diese Objektorientierung quasi die Kernfunktionalität des Systems ist, zusammen mit einem automatischen Admininterface. Aber eigentlich ist diese OO ja auch eher ne Philosophie als ein Feature. Und dieser Post nicht Tipp, sondern Pädagogik ;)!
Okay, so hatte ich diesen Post auch verstanden. Hat bei mir auch durchaus was ins Rollen gebracht, weil ich gerade dabei bin mir ein CMS für den Privatbetrieb selbst zu bauen.
Drupal kann ich aber nur wärmstens empfehlen. Man sollte sich vom etwas uncooleren Look nicht abschrecken lassen - unter der Haube ist es ein sehr mächtiges System. Es gibt hunderte Module und selbst für ganz individuelle, tiefergehende Modifikationen braucht man nicht im Code herumhacken, kann alles in externen Dateien machen.
Was verstehst du unter einem "automatischen Admininterface" ?
Das kommt vielleicht nicht so raus in dem Artikel, stimmt: Also unter dem automatischen Admin finde verstehe ich quasi eigentlich ein Backend mit Rechten und Pflegbarkeit. Hört sich blöd an, aber wenn man bedenkt, dass man bei diesen OO-Frameworks das komplette Datenmodell und damit auch die Tabellenstruktur selbst definieren kann, da ist das mit dem Backend gar nicht so trivial.
Das Backend muss ja aus den Definitionen generiert werden. Bei Ruby on Rails zum Beispiel muss man ja das Backend erst noch selber programmieren, auch wenn das zugegebenermaßen recht schnell geht. Bei Django hingegen passiert genau, was ich geschrieben habe. D.h. wenn man seine Klassen definiert hat, dann konfiguriert man das Admin-Backend als Modul hinzu, und schwupp haste Pflegbarkeit (mit allen 1:n, n:n usw. Beziehungen). Bei Expression Engine geht das zwar ähnlich, nur da kriegen die User meiner Meinung nach zu viel Infos im Backend. Riot hab ich lang nicht mehr getestet, war damals aber noch besser als Django.