Zope2 und Zope3 im Vergleich

Einige Dinge, die in Zope2 selbst programmiert bzw. durch Produkte nachinstalliert werden mussten, sind im Zope3 bereits enthalten.

Allgemeines

TTF-Development gibt's ab Zope3 nicht mehr

Unter Zope2 konnte man umfangreich im Browser entwickeln. Dazu mussten lediglich Python-Skripts per ZmI abgelegt/bearbeitet werden. Auf diese Weise konnten im laufenden Betrieb Änderungen an der Serverlogik durchgeführt werden. Das geht unter Zope3 nicht mehr.

Eng damit verbunden ist eine bessere Trennung von Code und Daten. In Zope3 liegt in der ZodB kein Programmecode mehr - nur noch Objekte. Jeglicher Programmcode ist im Filesystem angesiedelt - als Python-Paket

Das ZmI unter Zope2 und Zope3

Unter Zope2 war das ZmI eine Welt, alle anderen Seiten waren eine andere. Dieses Prinzip ist mit Zope3 hinfällig. Das ZmI ist in Zope3 nichts weiter als miteinander verlinkte BrowserViews, die an den ContentObjects hängen und die Bezeichnung ZmI damit eigentlich hinfällig. Man kann das Design der angezeigten BrowserViews zentral steuern (Stichwort SkiNs).

Man sollte bedenken, dass die Dinge, die man unter Zope2 per ZmI gemacht hat, unter Zope3 ganz normale Python-Methoden sind - es gibt keinen Grund mehr zwischen ZmI und dem Rest des Servers zu unterscheiden.

Erzeugen von Content-Klassen sammt Formularen

In Zope2 wurde ein Produkt namens Archetypes benutzt, um neue Content-Objektklassen zu generieren. Solche Objektklassen benötigt man z.B. für Contentmanagement - ein Artikel in einem Onlinemagazin ist z.B. eine Objektklasse mit den Eigenschaften Titel , Text , Liste der Bilder , Autor , ...

Ab Zope3 geht das auch mit Bordmitteln (siehe ContentObject ).

Link zu CMF-Beispielen: http://www.zope.org/Products/CMF/docs/PortalDesigns.txt/view

Content in der ZodB und ausserhalb

Zumindest der RootFolder liegt immer in der ZodB. Wenn in der ZodB nach Objekten gesucht, hangelt sich üblicherweise der Traverser die ConTainer der ZodB entlang, bis der Pfad in der UrL abgearbeitet ist. Allerdings kann man als Entwickler den TraVerser^? beeinflussen und so z.B. als Unterobjekte eines "fake-Containers" Objekte zurückliefern die beispielsweise SQL-Abfragen repräsentieren. Es ist auf diese Weise kein Problem, sämmtliche Inhalte der ZopeInstance in relationalen Datenbanken vorzuhalten. Auch können externe daten auf diese Weise leicht indiziert werden (z.B. per CataLog).

Produkte vs. Packages

Unter Zope2 gab es das Konzept der Produkte - vereinfachte gesagt: Zope-Module. unter Zope3 funktioniert das anders. Zope3-Module sind einfache Python-Packages. Sobald also ein Verzeichnis im Python-Suchpfad eine Datei namens __init__.py enthält, kann man dieses Package sowohl unter Python als auch unter Zope3 benutzen.

Beschreibungen von Objekten durch InterFaces

Objekte, die InterFaces implementieren besitzen damit eine sog. formalisierte API . Wo es in Zope2 oft nötig ist, sich in anderem Code umzusehen, um zu wissen, wie man Objekt X benutzt, braucht man sich bei Zope3 nur das entsprechende InterFace anzuschauen.

Komponenten mit Registrierungspflicht

Zope3 baut auf eine Komponenteninfrastruktur, wobei Vererbungsbeziehungen zwischen Klassen an Bedeutung verlieren. Über InterFaces geben Klassen zu erkennen, dass sie bestimmte Eigenschaften haben. Will man weitere Klassen mit ähnlichen Eigenschaften erzeugen, so müssen diese anderen Klassen einfach die selben InterFaces "Implementieren" - es ist keine Ableitung von ähnlichen Objekten bzw. isInstance() -Abfragen zum Testen von Objekten nötig.

Da Zope3 nur aus Python-Klassen besteht, ist theoretisch jede Klasse sofort durch Skripte nutzbar. Damit man auch mal etwas ausprobieren kann, ohne dass das den laufenden Betrieb beeinflusst, muss man jegliche Klassen, die eingesetzt werden sollen, erst registrieren.

Das geschieht entweder per ZcmL (z.B. für ein ContentObject) oder auch per SitE-Manager (z.B. bei einem UtilitY).

Trennung von Konfiguration und Code

Mit der Einführung der Konfigurationssprache ZcmL wurde die Konfiguration (z.B. das Setzen von Zugriffsberechtigungen) aus dem Python-Code herrausgenommen. Ziel war, dass Zope-Komponenten leichter zu konfigurieren sind. In Zope3 kann man dadurch die Klassen (-> Komponenten) in Python programmieren und die ganze Konfiguration per ZcmL leicht zugänglich machen, wodurch für das Anpassen von Berechtigungen, etc. keine Änderungen am Code mehr nötig sind.

Umstieg von Zope2 auf Zope3

Man kann in Zope3 keinen Code aus Zope2 weiterverwenden, der über reine Python-Klassen hinausgeht.

Spezielles

Pluggable Authentication Utility

Unter Zope3 existiert ein Plugin-System ( PaU ), um mit Anmeldedaten von Benutzern umzugehen. Unter Zope2 existierte etwas ähnliches, das jedoch weniger flexibel ist.

Neuigkeiten in Zope3.3

Auf folgender Seite sind die Änderungen zwischen Zope3.2 und Zope3.3 beschrieben:

http://kpug.zwiki.org/WhatIsNewInZope33
[Zurück zum Start]