6. Zope

Einordnung von Zope
Objekte in Zope
Publishing in Zope
Environment von Zope
Sicherheit
Sprachen

6.1 Einordnung von Zope

Zope steht kurz für Z Object Publishing Environment. Verwendet man es in seinem vollen Umfang, so ist es eher als Application Server zu sehen. Neben den üblichen Features für Web-Frameworks werden unter anderem ein eigener Web-Server mit HTTP-, FTP- und CGI-Unterstzützung, aber auch eine eigene Benutzerverwaltung und ein eigenes Caching-System mitgeliefert.

Der größte Teil von Zope wurde dirket mit Python programmiert, aus Gründen der Performance einige Bereiche jedoch auch in C und C++. Daher ist Zope auf nahezu allen Systemen die Python unterstützen verfügbar. Es können, wenn gewollt, alle vorhandenen Python-Module verwendet werden. In den Grundeinstellungen wird dieses aus Sicherheitsgründen aber unterbunden.

Der gesamte Quellcode liegt offen vor und darf verändert werden. Eine kommerzielle nutzung von Zope ist ebenfalls möglich, für diese werden keine weiteren Gebühren verlangt. Hinzu kommt eine große Community und Nutzergemeinde, welche die Entwicklung ständig vorantreiben.

Zope ist primär auf dynamische Anwendungen ausgelegt und bietet daher von Grund auf eine Möglichkeit für Sessions. Ein grundlegendes Prinzip ist die Trennung von Gestaltung, Logik und Daten. Zur Verwaltung der Daten wird das bereits integrierte CMF (Content Management Framework) verwendet, welches eine ganze Reihe an Schnittstellen für die verschiedensten Datenbanken anbietet. Die Gestaltung von Seiten wird über Page-Template geregelt, die Logik wird mit Hilfe von Python-Skripten realisiert.

Da Zope selbst keine eigenen Produkte, wie beispielsweise einen Web-Shop oder ein Foren-System, bereitstellt, sondern darauf ausgelegt ist, dass andere Entwickler ihre Anwendungen einbinden, existiert eine sehr einfache Möglichkeit zum einbinden neuer Produkte. Diese können direkt über ein Web-Interface entwickelt werden, oder aber auch, durch einfaches Hinzufügen in den entsprechenden Zope-Ordner, aufgenommen werden. Dies wird besonders deutlich an der großen Anzahl der auf Zope basierenden Web-Frameworks. Das wohl bekannteste und meist verbeitetste ist das grafische Content Management System Plone.

Da, wie später noch erläutert wird, Zope ein typischen Mehr-Benutzer-System ist, besteht die Möglichkeit alle Aufgaben direkt über ein Web-Interface durchzuführen (Through-the-Web-Management). Eine kurze Übersicht ist in Abbildung 6.1.1 zu sehen. Der Vorteil dieser Technik ist, dass Benutzern, die Zope beispielsweise als Kunden verwenden, kein direkter Zugriff auf das lokale Dateisystem des Servers gewährt werden muss. Hinzu kommt noch die Möglichkeit, Schritte, auch schon viele Ebenen in der Vergangenheit, rückgängig zu machen. Dies wird durch eine detallierte History- und Undo-Funktion realisiert.


Abbildung 6.1.1: Zope Benutzeroberfläche

6.2 Objekte in Zope

Wie im vollen Namen von Zope bereits enthalten, spielen Objekte hier eine wichtige Rolle: Alle Elemente die man in Zope verwenden kann, werden als Objekte, auch mit den typischen Eigenschaften, behandlet. Einige der wichtigsten vordefinierten Objekte sind Ordner, Page Templates, Produkte und Skripte.

Zu Objekten gehören natürlich auch die typischen Eigenschaften. Diese sind im folgenden, versehen mit eine Zope-Beispiel, aufgeführt:

Alle vorhanden Objekte liegen innerhalb einer internen objektorientierten Datenbank (ZODB) und können dort verwendet werden. Dieses Prinzip ist unter anderem auch bei Rails zu finden. Objekte persistent zu hinterlegen bietet sich bei Python schon deshalb gut an, da dies durch die Sprache bereits unterstützt wird (pickling, unpickling). Auch das Importieren und Exportieren von Objekten wird durch eine solche Form der Speicherung vereinfacht. Objekte sind aber nicht nur selbst definierte Templates, man beispielsweise beliebige Dateien hochladen und diese in der ZODB hinterlegen.

Auf den einzelnen Objekten können dann Transaktionen durchgeführt werden. Dazu gehört beispielsweise schon weiter oben genannt das Rendern von HTML oder das Übermitteln von Bilddaten. Diese Transaktionen werden immer vollständig oder gar nicht ausgeführt. Tritt ein Fehler auf, so wird ein Rollback gemacht, so dass der alte gültige Zusand weiter gültig ist.

Der Objekt-Baum, der in der ZODB aufgebaut wird, kann man als eine Art virtuelles Dateisystem verstehen. Entsprechent kann auch auf Objekte innerhalb anderer Objekte zugegriffen werden. Eine weitere Technik die Zope anbietet ist die Akquisition. Ein Objekt kann demnach Verhalten durch Enthaltensein, in einem anderem Objekt, erhalten. So reicht es aus, das Verhalten an einer Stelle zu ändern und es wird automatisch an allen anderen übernommen.

Eine typische Anwendung der Akquisition sind der HTML-Footer und der HTML-Header. Diese möchte man im Normalfall über eine ganze Reihe an Seiten konsistent halten. Mittels Akquisition reicht es nun aus, den Footer und den Header an der obersten Stelle zu definieren, an der er benötigt wird. Ist ein Objekt in diesem Objekt, oder weitern Unterobjekten, enhalten und es ruft dieses Objekt auf, dann wird so lange der Baum nach oben durchsucht, bis das entsprechende Objekt gefunden wird.

6.3 Publishing in Zope

Wie bei allen Web-Anwendungen geht es darum, dem Benutzer Inhalte oder Services bereitzustellen. Auch dies ist Teil von Zope und wird elegant mittels Objektorientierung durchgeführt. Bei Zope werden, im Gegensatz zu den meisten anderen Servern, kein URLs auf lokale Dateien gemapt, sonder URLs auf Objekte in der ZODB. Diese werden dann nur noch entsprechend ausgeführt und übermittelt.

Bei Zope wird das gesamte Internet als Container in Containern, also nichts anderes als Objekte in Objekten, verstanden. Wie elegant eine URL auf ein Objekt abgebildet wird, soll im folgenden Beispiel verdeutlicht werden:

Gegeben sei die URL "http://www.zope.org:80/info/zodb&id=4". Das Objekt URL kann nun in die folgenden fünf Teilobjekte aufgelöst werden:

Die ersten drei Teilobjekte sind für die konkrete Zope-Instanz in diesem Beispiel uninteressant. Als erstes wird also der Dokumenten-Teil betrachtet. Dieser wird bei Zope nach dem folgenden Muster betrachtet: Beginne im Wurzel-Verzeichnis und nimm dir dort das Objekt "info". Nehme dir aus dem Objekt "info" das Objet "zodb" und führe dies mit dem Argument "id=4" aus. Das Objekt "zodb" wird also beispielsweise dazu angestoßen eine HTML-Seite zu rendern.

6.4 Environment von Zope

In Abbildung 6.4.1 ist der Aufbau von Zope schematisch dargestellt. Komponenten sind durch Rechtecke symbolisiert, Verbindungen durch Linien zwischen den Komponenten.


Abbildung 6.4.1: Zope-Schema
Wie in Abbildung 6.4.1 deutlich wird, ist Zope aus fünf größeren Komponenten zusammensetzbar. Die Komponenten "Product" und "ZClass" können jeweils beliebig oft auftreten.

In der oberen Hälfte des Schaubildes ist zu erkennen, das Zope als Stand-Alone-Server und auch hinter einem bereits existierenden Server betrieben werden kann. Im ersten Fall greifen die Clients direkt über den ZServer auf Zope zu, im zweiten wird ein Umweg über der vorhandenen Server und beispielsweise CGI gemacht.

6.5 Sicherheit

Bei Zope handelt es sich um ein typisches Mehr-Benutzer-System. Diese (Benutzer) werden gesondert für eine Zope-Instanz angelegt und müssen nicht mit denen des lokalen Systems übereinstimmen. Welche Rechte ein Benutzer auf ein bestimmtest Objekt hat wird per "Safe-Delegation" gelöst. Ein Benutzer kann für ein Objekt bestimmte Rechte zugewiesen bekommen. Diese gelten nur für dieses konkrete Objekt und alle seine Unterobjekte (wenn nicht anders eingestellt). So ist es möglich auf einer Zope-Instanz beispielsweise mehrere Seiten wie "www.spam.de" und "www.eggs.de" zu betreiben, ohne dass diese sich gegenseitig beeinflussen können.

Die Rechtevergabe ist vergleichbar mit der, der aktuellen Windows-Server. Benutzer werden durch Rollen repräsentiert und können durch Security Policies bestimmte Rechte zugewiesen bekommen. Die Security Policies beziehen sich immer auf einen bestimmten Kontext, was im Falle von Zope Objekten entspricht.

Hinzu kommt die Beschränkgung, dass ein normaler Benutzer keinen Zugriff auf das lokale Dateisystem des Servers hat und schädliche Software nur sehr geringe Schäden verursachen kann. Aus diesem Grund sind auch, wenn nicht anders eingestellt, für Benutzer mit geringen Rechten nur sicherheits-unkritische Python-Module verfügbar.

6.6 Sprachen

Prinzipiell stehen für Zope dri verschiedene Sprachen, in vier Ausprägungen zur Verfügung:

Diese lassen sich gruppieren in Darstellung und Logik. DTML und ZPL fallen in die erste Gruppe, interne und externe Skripte in die zweite. Mit der DTML und der ZPT wird die Darstellung (strukturelle Logik) modelliert, mit den Skripten die Anwendungslogik.

Die DTML ist der erste Ansatz, der für die Verbindung von dynamischen und statischen Inhalten von Zope verwendet wurde. Die statischen Teile einer HTML-Seite können weiterhin so erzeugt werden wie üblich, die dynamischen werden durch spezielle Tags ersetzt. Diese Tags werden dann beim Rendern der Seite durch entsprechenden Inhalt ersetzt. Dieser Ansatzt ähnelt sehr stark PHP, da eine nahezu beliebige Mischung von Layout und Logik möglich ist. So kann beispielsweise direkt Python-Code ausgeführt werden. Hinzu kommt, dass viele grafischen HTML-Editoren ihnen unbekannte Tags automatisch entfernen und so bei jeder Änderung am statischen Teil, der dynamische wieder eingepflegt werden muss. Deshalb gilt die DTML als veraltet, wird aber aus Kompatibilitätsgründen noch mit ausgeliefert. Ein Beispiel findet sich im nächsten Code-Block.

<dtml-var standard_html_header>
<h1>Price list for <dtml-var title></h1>
<p>Hemp Bag $2.50</p>
<p>Silk Bag $5.00</p>
<dtml-var standard_html_footer>
In diesem Beispiel werden in der ersten und der letzten Zeile der Footer bzw. der Header der HTML-Seite eingefügt. Diese sind selbst wieder beliebige Objekte (welche zu HTML gerendert werden können) und werden, wie oben bereits beschrieben, durch Akquisition eingebunden. Wie in der zweiten Zeile zu sehen ist, können nicht nur Objekte eingebracht werden, sonder auch Variablen des aktuellen Kontext. Durch Verwendung anderer Elemente, wie beispielsweise dtml-in an Stelle von dtml-var, ist es möglich strukturelle Logik zu programmieren, aber auch komplexe Python-Ausdrücke sind möglich.

Die ZPT gilt als Nachfolger der DTML und ist im Bereich der Funktionalität zu ihrem Vorgänger beschränkt worden. So ist es nur noch sehr begrenzt und mit relativ hohem Aufwand möglich Logik in das Layout zu mischen. Dies muss nun nahezu, wie auch vorgesehen, mit Python-Skripts durchgeführt werden. ZPT ist, im Gegensatzt zur DTML, XML- und XHTML-konform. Dies verbessert die Lesbarkeit und die Aussagekraft des Layouts und verhindert zusätzlich, dass grafische Editoren die unbekannten Tags aus dem Code entfernen. Ein Beispiel zu ZPT findet sich im nächsten Code-Block.

<html>
<head>
<title tal:content="here/title">dummy title</title>
</head>
<body>
<table>
<tr tal:repeat="item container/objectValues">
<td tal:content="item/getId"></td>
<td tal:content="item/meta_type"></td>
<td tal:content="item/title"></td>
</tr>
</table>
</body>
</html>
Der Aufbau der Sprache ist der bereits im Abschnitt zu "Kid" beschriebenen sehr ähnlich, jedoch kann, wie oben beschrieben, kein beliebiger Python-Code ausgeführt werden. In diesem konkreten Beispiel wird zu Beginn der Inhalt des Title-Elements ersetzt. Innerhalb des Body-Elements wird eine Tabelle über alle in dem aktuellen Objekt enthaltenen Unterobjekte aufgebaut.

Mit Hilfe von internen und externen Skripten wird unter Zope die Anwendungs-Logik programmiert. Dies geschieht im Normalfall mit Python, kann aber auch, wenn installiert, mit Perl implementiert werden. Interne Skripte haben nur einen beschränkten Zugriff auf die Python-Komponenten, um die Sicherheit des Gesamt-Systems nicht zu gefährden. Beispielsweise ist mit ihnen kein Zugriff auf die Daten des lokalen Systems möglich. Externe Skripte hingegen, können jedes Python-Modul verwenden. Aus diesem Grund werden diese auch nur relativ selten verwendt. Ob ein Benutzer Zugriff auf interne, externe oder gar keine Skripte hat kann durch die Sicherheitsregeln festgelegt werden.