Web-Weaver

Motivation

»The Web is a writing environment.« (Dave Winer)

Was ist ein CMS?

Template Mechanismus

Workflow

Write Once — Publish Everywhere

Abgrenzung zu Web-Frameworks auf der einen und reinen Template-Engines auf der anderen Seite.

Web-Frameworks (zum Beispiel das in Python geschriebene Twisted) stellen Methoden und Objekte zur Programmierung von Web-Anwendungen zur Verfügung.

Reine Template-Engines (z.B. Cheetah) sind in erster Linie dazu gedacht, die Entwicklung von CGI-Anwendungen zu vereinfachen.

Warum Open Source?

Entgegen einem weit verbreiteten Irrtum sind Open-Source-Applikationen nicht unbedingt billiger und schon gar nicht umsonst! Der Vorteil von Open-Source-Anwendungen liegt in der Verfügbarkeit des Quellcodes. Dies gibt auf der einen Seite eine große Investitionssicherheit (wir haben im MPIWG schon einige Projekte aufgeben resp. unter großem Aufwand umschreiben müssen, weil die zugrundeliegende Software — in unserem Fall war es zum Beispiel HyperCard — nicht mehr weiterentwickelt wurde und schließlich auf »modernen« Computer gar nicht mehr lief) und zum anderen gibt es die Möglichkeit, die Software anzupassen und umzuschreiben, bis sie auf die wissenschaftlichen Anforderungen paßt.

Alternativen zu Content Management Systemen

Wikis sind Webanwendungen, die einmal das Publizieren im Netz unterstützen und gleichzeitig einen Mechanismus besitzen, der das automatische Setzen (interner) Links erlaubt.

Welche Stärke Wikis gerade in einem Intranet eines Instituts entwickeln können, hat Helmut Hayd eindrucksvoll auf dem letzten Linux-Tag der MPG demonstriert.

Frameworks und Template-Engines (siehe oben) können unter bestimmten Veraussetzungen durchaus eine Alternative zu herkömmlichen CMS sein. Das gilt insbesondere, wenn große Datenmengen aus Datenbanken heraus mit Hilfe von Scriptsprachen für das Web aufbereitet werden müssen. (Beispiel: CDLI)

CMS für den Desktop

Frontier unterscheidet sich sehr stark von allen anderen hier vorgestellten CMS. Obwohl es durchaus als Web-Application-Server (siehe unten) eingesetzt werden kann (dann allerdings nur unter Macintosh und Windows), ist es m.E. vor allem dann sinnvoll, wenn es als Desktop-Application zur Erstellung statischer Webseiten eingesetzt wird.

Frontier hat eine sehr lange Geschichte. Ich selber arbeite seit 1996 damit. Damals war es eine freies Programm (»frei« im Sinne von »Freibier«), wurde dann aber wieder kommerziell als Web-Application-Server zusammen mit dem aufgesetzten CMS Manila oder dem Desktop-Server Radio UserLand von der Firma Userland vertrieben. Diese kommerziellen Versionen von Frontier gibt es auch weiterhin. Doch seit Mitte dieses Jahres wird der Frontier-Kernel unter der GPL als Open Source zur Verfügung gestellt.

Frontier ist ein Produkt für den Einzelkämpfer — daher gibt es auch keinen Workflow-Mechanismus — der es zudem auch noch liebt, in Outlines zu schreiben und seine Ergebnisse schnell im Web publiziert haben möchte. Treffen diese Voraussetzungen zu, ist Frontier aber nahezu unschlagbar.

Frontier besitzt eine eigene, C-ähnliche Skriptsprache, UserTalk genannt. Außerdem ist Frontiers Objektdatenbank ähnlich aufgebaut, wie die Objektdatenbank in Zope. Frontier eignet sich daher auch zum »rapid prototyping« von Zope-Anwendungen. (Beispiel: VLP)

»Monolithische« CMS

Als »monolithisch« bezeichne ich Content-Management-Systeme, die wie aus einem Guß daherkommen. Zwar lassen sich Templates und in der Regel auch der Workflow weigehend an die Bedürfnisse der Nutzer anpassen und manchmal sind auch Schnittstellen für sogenannte Plug-Ins vorhanden, mit denen das System erweitert werden kann, aber die Entwicklung weitergehender Applikationen aus diesen CMS heraus ist in der Regel nicht vorgesehen. Die meisten dieser Applikationen sind in PHP geschrieben und setzen als Datenbank MySQL voraus.

Es gibt sehr viele solcher Systeme. Im Folgenden werde ich einige vorstellen, die ich prototypisch für diese Art von CMS halte.

drupal und Mambo sind zwei typische Vertreter dieser eher kleinen CMS. Sie sind schnell installiert und für kleinere bis mittelgroße Auftritte durchaus leistungsfähig genug.

Typo3 ist zwar auch ein PHP-basiertes, monolithisches CMS, spielt aber schon in einer anderen Liga. Mit Typo3 lassen sich — und wurden auch schon — »Enterprise«-Anwendungen bauen. Diese Leistungsfähigkeit erkauft man sich mit einer komplizierteren und eher abschreckenden Installation und Administration.

Das gleiche gilt für Bricolage, das in Perl geschriebene CMS. Es ist vielleicht sogar noch einen Kick leistungsfähiger als Typo3, dafür ist aber unter Umständen die Installation und Adminstration noch etwas komplizierter. Perl-Hacker werden es dafür lieben. ;o)

Web-Application-Server

Im Gegensatz zu den oben genannten »monolithischen« CMS stehen Web-Application-Server. Sie besitzen zwar in der Regel schon out-of-the-box einen Template-Mechanismus, viele andere CMS-Funktionen muß man aber erst auf Basis dieser Server entwickeln oder zusätzlich runterladen.

Dies scheint auf den ersten Blick mühselig und unnötig. Aber damit erhält man eine nahezu grenzenlose Flexibilität. Nahezu jede erdenkbare Form von Web-Anwendungen lassen sich mit solchen Web-Application-Servern entwickeln. Und das ist gerade im Wissenschaftsbereich, wo man doch in vielen Fällen mehr will, als ein einfaches Redaktionssystem, ein nicht zu unterschätzender Vorteil. Und wenn man doch mal ein einfaches CMS out-of-the-box benötigt: Für die meisten Web-Application-Server gibt es die natürlich auch schon. Meistens sogar mehrere zur Auswahl.

Web-Application-Server in Java

Helma ist ein in Java geschriebener Web-Application-Server. Er entstammt einer Gruppe von Programmierern aus dem Umfeld des Österreichischen Rundfunks und Fernsehens (ORF), der auch heute noch seinen gesamten Webauftritt mit Helma fährt, darunter auch den beliebten Nachrichtendienst FutureZone.

Helma ist zwar in Java geschrieben, wird aber intern in JavaScript programmiert.

Neben dem Auftritt des ORF ist die Weblog-Software Antville ein weiterer Beweis für die Leistungsfähigkeit von Helma.

Außer der Weblog-Software Antville gibt es meines Wissens noch kein fertiges CMS auf Basis von Helma, allerdings sieht es so aus, als ob Antville in diese Richtung »aufgebohrt« werden soll.

Die Verbindung von CMS und Wiki

SnipSnap ist ein Klone der von Christian Langreiter entwickelten Software Vanilla, die ursprünglich mal ein besseres Manila werden sollte. Während Vanilla darunter leidet, daß es in der doch etwas exotischen Programmiersprache Rebol entwickelt wurde (wer hat die schon auf seinem Server?), ist SnipSnap komplett in Java geschrieben. Vanilla und SnipSnap versuchen die Symbiose eines CMS mit einem Wiki, ein meines Erachtens durchaus reizvoller und interessanter Ansatz, speziell für den Bereich Wissensmanagement.

SnipSnap wurde am Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik (FIRST) entwickelt.

Zope als Web-Application-Server

Zope ist der Open-Source-Web-Application-Server mit der meines Wissens größten Verbreitung und einer unglaublichen Flexibilität. Bis auf einen kleinen C-Kernel ist Zope komplett in Python geschrieben und ist daher auf fast allen Betriebssystemen zu Hause. Ähnlich wie Frontier besitzt Zope eine eigene Objekt-Datenbank, in der es seine Objekte speichert. Daneben gibt es aber Adapter zu nahezu allen SQL-Datenbanken (z.B. MySQL, PostgreSQL, Adabas, Oracle, Ingres). Zope skaliert beliebig und ist zusammen mit dem ZEO, dem Zope Enterprise Obejct Manager, auch Cluster-fähig und somit in der Lage, hochverfügbare Applikation zu liefern.

Plone ist das am weitesten verbreitetste CMS unter Zope. Es setzt auf dem CMF, dem Content Management Framework auf und ist erst einmal ein ziemlich mächtiges CMS out-of-the-box.

ZMS ist ein Open-Source-CMS unter Zope, das speziell für den medizinisch-wissenschaftlichen Bereich entwickelt wurde. Es ist in seiner Spzialisierung durchaus anspruchsvoller und auch etwas schwieriger zu adminstrieren.

Silva ist ein CMS unter Zope, daß einen Schwerpunkt im Dokument-Management besitzt und mit einer XML-basierten Metadatenunterstützung brilliert. Wer Applikationen in diesem Bereich benötigt, sollte sich Silva durchaus einmal ansehen.

Fazit

Was für ein CMS soll man nun wählen? Wie immer kommt es auf das Einsatzgebiet an. Die von mir »monolitisch« genannten CMSe sind sicher nur dann interessant, wenn man schnell mal ein kleines CMS hinzaubern will oder muß, für den kompletten Webauftritt eines Institutes sind sie eher nicht geeignet (wobei Typo3 und Bricolage da aber schon an der Grenze liegen).

SnipSnap ist wegen seiner Kombination aus Wiki und CMS für gewisse Intranet-Anwendungen sicher einer Überlegung wert (Stichwort: Wissensmanagement, Wissenssammlung). Hier steht es aber in Konkurrenz zu richtigen Wikis, die wiederum auf der anderen Seite nicht unbedingt die Flexibilität und Erweiterbarkeit von SnipSnap besitzen (TWiki vieleicht ausgenommen).

Für große Anwendungen ist sicher ein Web-Applikation-Server die richtige Wahl. Am MPIWG haben wir sehr gute Erfahrungen mit Zope gemacht und fast unseren gesamten Webauftritt darauf umgestellt. Interessanterweise hat sich herausgestellt, daß es sinnvoller war, direkt auf Zope aufzusetzen, anstatt Plone oder das CMF als CMS-Framework zu nutzen. Das kann aber auch an den speziellen Anforderungen der Wissenschaftsgeschichte liegen.

Frontier dagegen ist nur etwas, das man dem publikationswütigen und/oder experimentierfreudigen Kollegen/Wissenschaftler mal installieren kann. Der hat aber dann sicher sehr viel Spaß damit.