ZPublisher

Eine grundlegende Komponente bei der Auslieferung (publishing) von Webseiten.

�bersetzt von http://www.dieter.handshake.de/pyprojects/zope/book/chap3.html#ZPublisher

---

Der ZPublisher ist f�r die folgenden Aufgaben verantwortlich:

1. Bildung der SpezialObjekte REQUEST und RESPONSE,

2. Besorgung der Argumente, entweder im AbfrageString? des RequestLocator?-s (wenn die RequestMethod? [GET]? oder [HEAD]? ist) oder im RequestBody? (f�r die anderen RequestMethod?-s) und n�tigenfalls Dekodierung derselben.

3. Konvertierung der RequestArgumente? basierend auf den TypeSuffix?-es(TypEndung?-en) der ArgumentName?-n,

4. Aufl�sen des Pfades des RequestLocator?-s in ein OBjekt?. (sog. TRaversal?),

5. Einleiten der UserAuthentication?

6. Aufruf des durch das TRaversal? lokalisierten Objekts oder Methode mit den erforderlichen oder verf�gbaren Parametern.

7. AusnahmenBehandlung? (ExceptionHandling?), falls Fehler w�hrend des Prozesses auftraten.

Nun etwas detaillierter zu diesen Aufgaben:

1. Bildung der SpezialObjekte REQUEST und RESPONSE,

   REQUEST enth�lt die kompletten Details des REquest?-s(ANfrage?). RESPONSE wird sp�ter die HTTPResponse? generieren. Seine Nethoden k�nnen von anwednungsspezifischen Teilen genutzt werden um diese Erzeugung zu beeinflussen.

2. Argumente besorgen

Der REquest?(ANfrage?) kann Argumente enthalten, die n�her bestimmen was getan werden soll bzw. Daten f�r die Aktion bereitstellen. Bei [GET]? und [HEAD]? requests sind die Argumente im AbfrageString? enthalten, bei anderen RequestMethod?-s sind sie im RequestBody?. Die Parameter sind oft verschiedenartig verschl�sselt und k�nnen auf verschiedene Art und Weise serialisiert werden. Der ZPublisher holt sie und entschl�sselt sie falls n�tig.

1. Konvertierung und Packen der Argumente.

   Mit der Ausnahme von FIles? sind alle [HTTP]?-Parameter Strings. H�ufig ben�tigen Funmktionen jedoch verschiedene DatenTypen? als Argumente: Zahlen, Datumsangaben, Datens�tze (structures). Nat�rlich k�nnten diese Funktionen die Umwandlung der DatenTypen? selbst vornehmen, es ist jedoch sch�ner dies zentralisiert zu tun. ZPublisher kann die erforlderlichen Umwandlungen bereitstellen. Er leitet untersucht die TypEndung?-en der Argumentnamen, interpretiert sie als REquest? um entweder den ArgumentWert? zum gegebenen Typ zu konvertieren oder um ihn mit anderen Werten in einen gr��eren Typ zu packen. Zum Beispiel: x:int=1 veranla�t ZPublisher den String-Wert "1" in den Integerwert 1 umzuwandeln und mit dem Argument x zu verkn�pfen. Ein Bezeichner kann mehrere TypEndungen? haben, zB. x:int:list=1. Als Ergebnis wird der Parameter x mit einer Liste als Wert definiert, diese Liste hat ein einziges Element, den Integer 1.

   ZPublisher erkennt verschiedene Arten von Endungen: ConVerter?-s, PAckagers?, ACtions?, ConTrollers?. Normalerweise sollten alle Bezeichner mindestens eine Endung jeder Art haben. D.h. es sollten zB. nicht zwei ConVerter?-Endungen vorkommen, ein ConVerter? und ein PAckager? w�re in Ordnung[24]?. Die Reihenfolge in welcher die Endungen der verschiedenen Arten auftreten ist unbedeutend.

2. 1 ConVerter?-s

   Sie wandeln (konvertieren) den Wert in einen angegebenen Typ um und erzeugen eine Ausnahme falls nicht m�glich. Alle ConVerter? akzeptieren ebenso FIle? values. Solche files werden eingelesen um einen String zu erhalten, der dann konvertiert wird. Zope unterst�tzt folgende ConVerter?:

   • float, int, long, string - wandelt in die entsprechenden Python-Typen um.

   • date - konvertiert in eine DateTime? object. Als Wert kommen alle vom DateTime? COnstructor? akzeptierten Strings in Frage, einschlie�lich DatumsString?-s, die in irgendeiner Weise in den USA erkannt werden und optional einen 'time'-Teil besitzen. Siehe dazu auch die ZopeAPI? in der ZopeHilfe?.

   • tokens - wandelt in eine Liste aus Strings durch splitten an den WhiteSpace?-s.

   • text - normalisiert die LineEndings?(ZeilenUmbrueche?). Dies ist n�tzlich f�r die Werte von TextArea?-Werten, zB benutzen MS Windows und Unix verschiedene ZeilenUmbruch?-s-Zeichen.

   • lines - wandelt in eine Liste aus Strings durch splitten an Zeilengrenzen.

   • required - wandelt in einen String, veranla�t eine Ausnahme wenn der String leer ist.

   • boolean - wandelt in einen Bool'schen Wert, ein leerer Wert wird zu false, jeder andere Wert zu true.

3. 2. PAckager?-s

PAckager?-s packen mehrere Parameter-Definitionen mit gleichem oder mit verwandten Namen in gr��ere Strukturen um sie einfacher zugreifbar zu machen. Zope unterst�tzt folgende PAckager?:

• list - Packt alle Parameter-Werte mit dem aktuellen Parameter-Bezeichner in eine Liste. Dies ist default-Vorgehensweise sobald im REquest? zwei oder mehr Definitionen mit derselben Bezeichnung zu finden sind. Der ListPackager? kann verwendet werden um eine Liste zu erhalten obwohl im REquest? nur eine ParameterDefinition? mit der gegebenen Bezeichnung vorhanden ist. Man benutzt dies gerne f�r die einheitliche Behandlung von MultipleSelection?-Eingaben entsprechenden Form-Feldern. Achtung: Falls keine Auswahl getroffen wird ("no items selected") mu� dies immer noch speziell abgehandelt werden da die Form-Steuerung erfolglos ist und keine ParameterDefinitionen? im REquest? vorhanden sind.

• tuple - Packt alle ParameterWerte? mit dem aktuellen ParameterBezeichner? in ein PYthon? tuple. Tuples sind den Listen �hnlich, jedoch read only (d.h. immutable in PYthon?).

• record - Der aktuelle ParameterBezeichner? mu� die Form name.attrribut haben. Der RecordPackager? sammelt alle ParameterDefinition?-en mit dem gleichem Namen in ein REcord? mit entsprechenden Attributen und stellt es unter diesem Bezeichner zum Zugriff bereit. Wenn, zB. die ParameterDefinitionen? person.name:record=dieter und person.email:record= existieren, so wird ein REcord? person erstellt mit den Attributen name und email und den Werten dieter bzw.

• records - Wie record, erzeugt jedoch ein Liste aus REcords?. Es bestimmt auf scheinbar magische Art wann ein neuer REcord? beginnen soll.

1. 3. ACtions?

Normalerweise ruft ZPublisher das beim TRaversal? ausgew�hlte Objekt auf um die HTTPResponse? zu erzeugen. Wenn aber der REquest? eine action enth�lt bestimmt diese action das aufzurufende Objekt.

ACtions? k�nnen zwei Formen haben: name:action_suffix=value oder action_suffix=value. Im ersten Fall bestimmt name das aufzurufende Objekt und value wird ignoriert; im zweiten Fall bestimt value das Objekt. Normalerweise wird die erste Variante in FormButton?-s verwendet, die zweite Variante wird verwendet, wenn die FormAction? von einem JavaScript? bestimmt wird. In beiden F�llen kann der Objekt-Bestimmer eine Folge von durch "/" getrennten PfadSegement?-en sein. Es wird im Kontext des beim TRaversal? bestimmten Objekts interpretiert. Die Auswirkung ist sehr �hnlich zur Erweiterung des RequestLocatorPath? durch den ObjectDesignator? (Objekt-Bestimmer). Dieses Feature gibt es um die Verarbeitung von Forms mit mehr als einem Button zu erleichtern. Jeder Button kann direkt die Methode bestimmen die seine Operation ausf�hrt.

Es gibt zwei verschiedene ACtions?-Typen: default und specific action. Eine default action kann von der specific action �berschrieben werden. Die default action verwendet die TypEndung? default_method (oder den Alias default_action) und die specific action verwendet method (bzw. ihre Alias action). (Letzten Satz auf Sinn pr�fen)

1. 4. ConTroller?-s

ConTroller?-s steuern wie ZPublisher die gegebenen ParameterDefinition?-en. ZPublisher nutzt folgende ConTroller?-s:

• default - Die Definition legt einen default value fest, welcher verwendet werden soll, wenn keine andere Definition f�r den gleichen ParameterBezeichner? vorhanden ist. Dies wird h�ufig f�r checkboxes verwendet. Normalerweise ist eine nicht ausgew�hlte checkbox ohne Auswirkung (not successful). Sie wird daher nicht zu den Form-Daten im REquest? beitragen, damit ist es schwierig den der checkbox entsprechenden Wert zur�ckzusetzen. Der default controller gestattet es, einen reset value f�r diesen Fall bereitzustellen.

• ignore_empty - Die Definition wird ignoriert wenn ihe Wert leer ist. Damit kann man die default Parameter der Python Funktionen anstatt der Definition verwenden.

1. TRaversal? (�berquerend)

W�hrend dem traversal, �berquert der ZPublisher die Webseite gem�� dem PathComponent? im ResourceLocator? des REquest?-s. (Ein [URI]? Pfad ist eine Folge von PfadAbschnitt?-en (PathSegment?-s).

ZPublisher traversiert dies in Schritten, einen f�r jeden PfadAbschnitt?. Bei jedem Schritt beginnt er mit dem aktuellen Objekt und hat eine Folge von PfadAbschnitt?-en zum Traversieren �brig. Er interpretiert den ersten Abschnitt als den accessor (Wegbereiter?) im KOntext? des aktuellen Objekts um zum n�chsten Objekt zu gelangen. Normalerweise wird der n�chste Schritt der �berschreitung dieses folgende Objekt als aktuelles Objekt nehmen und der erste Abschnitt des vorher restlichen Abschnitts wird verworfen. Der Prozess stoppt wenn der entweder alle PfadSegment?-e bearbeitet wurden oder wenn das aktuelle PfadSegment? auf kein neues Objekt zugreifen kann[26]?. Der zweite Fall zeigt f�r gew�hnlich einen Fehler an[27]?. ZPublisher beginnt die Traversierung beim RootObject und mit dem vollst�ndigen RequestLocatorPath?.

Wenn ein 'index_html'-Objekt im KOntext? des Objektes verf�gbar ist, das durch eine erfolgreiche �berquerung lokalisiert wurde, so wird ZPublisher diese index_html verwenden, wenn nicht, so wird er das gefundene Objekt verwenden. Dieses Verhalten ist �hnlich zu dem anderer WebServer?. (Diese schauen nach einer index.html im KOntext? des RequestLocatorPath? (meist ein Ordner) und geben es zur�ck.)

Die weiteren Teile dieser Seite sind nur f�r ProduktEntwickler? relevant. Andere Leser k�nnen sie �berspringen.

The remaining parts of this section are relevant only for product developers. Other readers may skip them.

ZPublisher provides two traversal hooks. As we said in the introduction, a hook is a step in a procedure where the application can take over control when the normal framework implementation does not fit its needs.

The first hook is called __before_publishing_traverse__. If defined, it is called at the start of a traversal step. It is defined when the step's current object has such an attribute. The attribute will be called with two arguments, the current object and the request object. Its return value is discarded, thus only its side effects are essential. Usually, it will modify the request object. The modification may be as simple as defining additional parameters or providing defaults. However, the request object also provides methods that change the path segments still to be traversed. Therefore, the hook can drastically change the traversal. This is used for example to implement virtual hosting or to facilitate internationalization. Products that use this hook are for example SiteAccess2? (for virtual hosting) and Localizer (a localization tool).

The second hook is called __bobo_traverse__. If defined, it customizes the "accessor" notion. As we have seen, during a traversal step, ZPublisher uses the first path segment as an accessor to find the next object in the current object's context. Its default behavior is to first check for an attribute of the given name, then for a (mapping) key, then fails. However, if the current object has an attribute __bobo_traverse__, then this function is called with the request object and the segment as parameters to determine the next object. It can even return a tuple of objects. In this case, the last element defines the next object while the preceeding objects define the path to this object replacing the current object. This hook is used, for example, to implement advanced features of ZSQL methods such as direct traversal.

During traversal, ZPublisher builds a sequence of objects visited during traversal to the final selected object. It makes the reverse list accessible as the request member PARENTS. PARENTS[0]? is the object's parent, the object visited before this object; PARENTS[1]? is the object's grand parent, and so on. The object itself is made available via the member PUBLISHED. 2.6.5. Initiate Authentication

Once ZPublisher has determined the object to be called during the traversal, it initiates authentication. It does not authenticate the user itself, but cooperates with other Zope objects, so called UserFolders? to fulfill this task.

First, ZPublisher determines which roles can call the object. Then, ZPublisher goes back along the chain of nodes it had visited during traversal (but in reverse order). It checks each node, whether it contains a UserFolder? instance and if it does, whether this user folder can authenticate a user with the required roles. If authentication is successful, ZPublisher places the resulting user object as AUTHENTICATED_USER into the REQUEST object. Otherwise, ZPublisher continues its search towards the site root. The highest UserFolder? will return the Anonymous user, if it cannot authenticate the user and calling the object does not require special roles. If ZPublisher has reached the site root without being able to find a user folder that authenticated the user with sufficient privileges to call the object, it raises an Unauthorized exception. If not overridden by application specific code (e.g. special user folders), such an exception is turned into an "Unauthorized" HTTP response. Such an HTTP response causes the browser to pop up a login dialog. 2.6.6. Call object/method

Now, that traversal has determined the object to call and the necessary authorization is checked, ZPublisher can call the object.

ZPublisher looks into the object and determines what parameters are mandatory or optional for the call. It then looks into the REQUEST object and then the objects context, in this order, to find such parameters. It then calls the object with the parameters found, raising an exception if a mandatory parameter has not been found.

ZPublisher calls the object inside a transaction. This makes is possible to undo most types of side effects of the call in case it should fail[28]?. If the call raises an exception, the transaction is aborted. When the call returns without exception, the transaction is committed and other requests can see potential effects by this call. 2.6.7. Handle errors

ZPublisher handles all errors that occur during its proper operation or exceptions raised during the object call. It turns them into appropriate HTTP responses.

-----------

Usually, the next traversal step will use this object as current object and the segment sequence with the first segment removed.