Der Applicationserver Zope erfreut sich als Open-Source-Plattform für Contentmanagement-Systeme großer Beliebtheit. Vor kurzem ist die von Grund auf neu entwickelte Version X3.0 des Python-Framework erschienen. Dieser Beitrag verrät, was sich geändert hat.

Spätestens seit Erscheinen des Contentmanagement-Systems (CMS) Plone[1] ist Zope ([2], [3]) aus der Welt der freien Web Application Server nicht mehr wegzudenken. Schon der Erfolg des Projekts zeigt, dass sich Zope durchaus mit Boliden aus der Java-Welt messen kann. Python als Programmiersprache der Zope-Welt sorgt für objektorientierten und modularen Quellcode. Weiterentwicklungen gehen damit so agil und flexibel vonstatten, wie man es sonst von Skriptsprachen des Web kennt.

Das CMF hilft bei der Neuentwicklung

Zope wird gerne als Plattform für CMS eingesetzt. Die meisten freien Zope-CMS (Plone[1], Silva[4], CPS[5]) benutzen das Content Management Framework (CMF). Dieses Produkt für Zope 2 brachte nicht nur die nötigen Werkzeuge für Contentmanagement-Systeme mit. Es war auch der erste Schritt in Richtung einer Komponenten-basierten Architektur. Technologien der Version 2 wie Zope Page Templates und die XML-Makrosprache TAL/METAL legen dafür den Grundstein.

Statt jedoch den verwinkelten Quellcode von Zope mühsam umzuschreiben, entschloss sich die Zope Corporation vor drei Jahren, den Neuanfang zu wagen. Die Erfahrungen aus der Entwicklung des CMF sollten in die Zope-Entwicklung einfließen. Da man sich längst dem Gedanken freier Software verschrieben hatte, stand das Projekt von Anfang an für die Community-Mitarbeit offen.

In großen und kleinen Entwicklertreffen (Sprints) auf der ganzen Welt entwickelten Zope-Erfahrene wie auch Neulinge die Software weiter. Bei der Qualitätssicherung halfen Methoden des Extreme Programming (XP), zum Beispiel Unit-Testing. Zudem konnten sich die Entwickler dank der bereits erfolgreichen stabilen Zope-Version 2 die Zeit lassen, gewisse Features in mehreren Iterationsschritten zu perfektionieren. Dabei waren sie sich nicht dafür zu schade, bereits geschriebenen Code wieder wegzuwerfen, um Funktionen anschließend besser zu implementieren.

Bessere Struktur durch Komponenten

Herzstück von Zope X3 ist die Komponenten-Architektur (siehe[6]). Sie setzt konsequent fort, was mit dem CMF begann – die Aufteilung der verschiedenen Zuständigkeiten (Datenspeicherung, Datenverarbeitung, Präsentation) auf zuständige Komponenten.

Die Objekt-Datenbank ZODB (Zope Object Database) ist schon aus Zope 2 bekannt. Sie erlaubt es, Objekte weitgehend transparent in der Datenbank zu persistieren, und zwar mit Enterprise-verdächtigen Features wie Transaktionen und Revisionierung sowie der Möglichkeit, verschiedene Storage Backends zu verwenden. Mit von ZEO (Zope Enterprise Objects) lassen sich sogar mehrere Zope-Instanzen zu einem Cluster zusammenfügen und so leicht skalieren.

Feiner Zugriffsschutz

Ein flexibles Sicherheitssystem schützt Komponenten sowie deren Attribute und Methoden durch Permissions. Will ein Benutzer auf solche geschützten Komponenten zugreifen, sei es über einen normalen Webbrowser oder auf anderen Wegen wie WebDAV oder XML-RPC, muss er autorisiert sein. Dabei authentifizieren und autorisieren austauschbare Komponenten die Benutzer. So lassen sich die Sicherheitsaspekte einer Applikation individuell für den Einsatzort anpassen, ohne die komplette Anwendung umzustricken.

Zope bringt nicht nur die richtigen Werkzeuge zur vollständigen Internationalisierung (I18N) von Applikationen mit, es ist auch selbst vollkommen internationalisiert. Dank der beteiligten deutschen Entwickler gehört eine deutsche Übersetzung von der ersten Stunde an zum Lieferumfang. Zahlreiche weitere Features, zum Beispiel der E-Mail-Versand per SMTP oder Sendmail, ein Event-Notification-System sowie die Unterstützung für XML-RPC, runden die Zope-Palette ab.

Paradigmenwechsel

Zope X3 räumt mit einigen Schwächen von Zope 2 auf. So erwartet die Vorgängerversion von allen Klasseninstanzen, dass sie die nötigen Attribute und Methoden für das Zusammenspiel mit Zope selbst mitbringen. Das führt dazu, dass Objekte mit unterschiedlichsten Methoden überladen sind, was die Anpassung dieser Funktionalitäten erschwert. Auch die Verwendung der Komponenten außerhalb von Zope ist damit praktisch unmöglich.

Zope X3 hält aus diesem Grund die einzelnen Komponenten so simpel wie möglich und implementiert jede Zusatzfunktionalität in weiteren Komponenten. Die Architektur enthält verschiedene Komponententypen:

• Content (Inhalt). Diese Komponente entspricht in der
  klassischen MVC-Lehre (Model, View, Controller) dem Modell.
  Inhaltskomponenten haben meist keine eigenen Methoden, sondern nur
  Attribute, in denen sie die zu speichernden Daten preisgeben. Diese
  werden in der Regel durch ein Datenschema in ihrem Typ und Wert
  genauer spezifiziert.
• Utilities sind vom Kontext unabängige Komponenten, die
  eine Aufgabe erledigen. Beispiele sind Datenbankverbindungen,
  Indizierung, E-Mail-Versand und Übersetzungskataloge.
• Adapter. Hierbei handelt es sich wohl um die mächtigste
  Komponentenart. Adapter erlauben es, bestehende Komponenten um neue
  Funktionalität zu erweitern, ohne dass die Komponente selbst
  modifiziert werden muss. Das ist vor allem dann nützlich, wenn
  ein Framework ein bestimmtes API voraussetzt. Selten entsprechen
  nämlich die eigenen Inhaltskomponenten dem fremden API. Beim
  Anpassen der Komponente wäre der Programmiergrundsatz der
  Gewaltenteilung verletzt. Stattdessen belässt man die
  Ausgangskomponente, wie sie ist, und implementiert einen Adapter,
  der zwischen ihr und dem gewünschten API vermittelt. Als
  Veranschaulichung kann der Adapter an einer Stereoanlage dienen,
  der den alten Plattenspieler mit dem modernen Verstärker
  verbindet.
• Views. Diese Komponenten entsprechen den vom MVC-Prinzip
  bekannten Views. Sie ermöglichen die Darstellung anderer
  Komponenten für den Benutzer. Ein Beispiel ist der Webbrowser,
  der mit Views bedient wird, die HTML produzieren. Views sind
  eigentlich nur spezielle Adapter, denn sie stellen anderen Objekten
  eine zusätzliche Funktion (nämlich die Präsentation)
  bereit.

Abstrakte Verträge durch Interfaces

Um ihre Unabhängigkeit von der Implementation zu gewährleisten, sucht Zope die Komponenten nicht anhand ihrer Klasse. Dazu dient vielmehr die Beschreibung ihrer Funktionalität durch Interfaces. Diese sind sozusagen der formale Vertrag zwischen zwei Komponenten, der Funktionalität in Form eines API zusichert.

Da Python von Haus aus keine Interfaces kennt, hat Zope sie kurzerhand erfunden. Die Zope-Datenschemata spezifizieren Datentypen zwar genauer als gewöhnlich, doch das ändert nichts an Pythons dynamischer Typisierung. Zope-Komponenten halten also möglicherweise, was ihr Interface verspricht, die Python-Sprachsemantik kann das aber nicht garantieren.

Listing 1 zeigt eine Beispielapplikation zur Verwaltung der Adressen von Freunden. Das dargestellte Interface ist ein Datenschema. Es beschreibt also eine Inhaltskomponente, und zwar die zu speichernden Adressdaten eines Freundes. Dabei reicht es natürlich aus, die Postleitzahl zu speichern und die sich daraus ergebenden weiteren Informationen (Wohnort und Bundesland) bei Bedarf nachzuschlagen.

Das »class«-Statement von Python wird hier zum Definieren eines Interface missbraucht, da Python ja selbst keine Interfaces kennt. Zudem macht Zope keinen Unterschied zwischen einem Interface, das Funktionalität durch Methoden beschreibt, und einem anderen, das ein Datenschema beschreibt. In beiden Fällen geht es um die Beschreibung eines API, sei es durch Methoden oder durch Attribute.

Einfache Inhaltskomponenten

Wer bereits persistente Klassen für Zope 2 geschrieben hat, kennt die Unzahl von Forderungen an sie und wird sich vielleicht geärgert haben: Minimum waren der Metatyp, die Sicherheitsdeklarationen und die für das Anlegen neuer Instanzen durch das Webinterface gebrauchten Erzeugenden-Methoden. Die Ansprüche sind nun auf ein Minimum gesunken. Persistente Objekte müssen sich nur noch um die ihnen anvertrauten Daten kümmern. Für den Rest sorgen die anderen Komponenten.

Abbildung 1: Ein Bearbeitungsformular, automatisch generiert aus dem Datenschema der Inhaltskomponente.

Listing 2 zeigt eine vollwertige Implementierung des »IBuddy«-Interface aus Listing 1. Wichtig ist dabei nur, dass die Klasse von »Persistent« erbt, damit die ZODB die Klasseninstanzen automatisch speichert. Zur Versicherung gegenüber anderen Komponenten deklariert man zudem, dass die Klasse das »IBuddy«-Interface implementiert.

01 from zope.interface import Interface
02 from zope.schema import Text, TextLine
03 
04 class IBuddy(Interface):
05     """Informationen ueber einen Freund"""
06 
07     first = TextLine(title=u"Vorname")
08     last = TextLine(title=u"Nachname")
09     address = Text(title=u"Adresse")
10     postal_code = TextLine(title=u"Postleitzahl")

01 from persistent import Persistent
02 from zope.interface import implements
03 from buddydemo.interfaces import IBuddy
04 
05 class Buddy(Persistent):
06     implements(IBuddy)
07 
08     def __init__(self, first='', last='',
09                  address='', postal_code=''):
10         self.first = first
11         self.last = last
12         self.address = address
13         self.postal_code = postal_code

Konfiguration per XML

Bei Version 2 müssen sämtliche Bibliotheken im Verzeichnis »Products« liegen, damit Zope sie importiert. Im Initialisierungsmodul jedes Pakets (»__init__.py«) befindet sich meist die Registrierung der Komponenten. Sicherheitsdeklarationen oder die Konfiguration von Browseransichten vermischen sich mit Anwendungscode.

Zope X3 räumt damit auf. So sind Erweiterungen zu Zope jetzt normale Python-Pakete. Das bedeutet, dass sie an beliebigen Stellen installiert sein dürfen, solange sie sich im »PYTHONPATH« befinden. Alles andere, was an Konfiguration der Komponenten anfällt, ist nun per Konfigurationsdatei verdrahtet: Sei es die Registrierung an sich, seien es die Sicherheitsdeklarationen oder Browseransichten. Das hat den Vorteil, Komponenten zeitweise oder ganz ausschalten zu können, ohne den eigentlichen Code modifizieren zu müssen.

Listing 3 zeigt die für eine Schema- basierte Inhaltskomponente typischen Konfigurationsdirektiven. Zunächst legen sie mit dem Tag »content« die Inhaltskomponente fest (Zeilen 5 bis 12). Das Beispiel beschränkt sich auf die Sicherheitsdeklarationen, die das Lesen (Zeilen 6 bis 8) und Schreiben (Zeilen 9 bis 11) von Daten an Buddy-Instanzen einschränken. Danach definiert die Datei zwei Formulare: »browser:addform« legt eine Eingabemaske fest, um Buddy- Objekte zu erzeugen (Zeilen 14 bis 20). Das Tag »browser:editform« erstellt ein Zope-Formular, um bereits existierende Buddy-Objekte komfortabel zu bearbeiten (Zeilen 22 bis 27).

Zope kann nämlich aus dem Datenschema, das im »IBuddy«-Interface definiert wurde, automatisch ein Formular generieren. So erhält man mit einem Schema, einer simplen persistenten Implementation und einigen wenigen Konfigurationsdirektiven bereits eine in der Browseroberfläche funktionierende Komponente – ohne selbst HTML-Code zu schreiben, siehe Abbildung 1.

Die letzte Direktive in Listing 3 (Zeilen 29 bis 33) sorgt dafür, dass ein entsprechender Eintrag im Menü des Zope- Webinterface erscheint, der uns zum Erstellen von Buddies einlädt. Allein die Existenz dieser Direktive verdeutlicht einen wichtigen Grundsatz in der Zope-3-Philosophie: Explizit ist besser als implizit. Daher werden die Programmierer von Zope-3-Software manchmal nicht um etwas Schreibarbeit herumkommen. Dafür wissen sie aber auch noch nach sechs Monaten, warum alles gerade so aussieht.

G Abbildung 2: Das Zope Management Interface (ZMI) von X3. Eigene Webanwendungen passen dieses Frontend an den konkreten Bedarf an.

E Abbildung 3: Das ZMI enthält aus Version 2 bekannte Funktionen, zum Beispiel die Datenbankadapter und den Cache-Manager.

Fazit

Zope hat schon seit langer Zeit eine große Fangemeinde, vor allem dank seiner Features, seiner Flexibilität und nicht zuletzt wegen Python. Der Einsatz in großen Projekten und Firmen beweist, wie ausgereift die Software ist. Mit der Version X3 ist Zope ein großer Sprung nach vorne gelungen. Es wird noch eine Zeit dauern, bis nicht nur die Software, sondern auch die neue Methodik Fuß fassen kann. Zope 2 hat also so schnell noch nicht ausgedient. Dennoch bietet die neue Version Anlass, um eigene Software schon mal fit für die Komponentenarchitektur zu machen.

Das Five-Projekt[8] ermöglicht trotz API-Inkompatibilität eine sanfte Migration nach Zope X3, ohne Version 2 gleich den Rücken zuzukehren. (ofr)