ReQUEST

Das SpezialObjekt REQUEST in genauer Betrachtung

REQUEST enth�lt die vollst�ndige Information �ber den aktuellen REquest?. Die wichtigste Information ist redundant (mehrfach vorhanden), in orginaler unverarbeiteter Form und in einer vorverarbeiteten Form f�r einfacheren Zugriff.

REQUEST pr�sentiert seine Daten als MappingObject[29]?. Die request Daten werden RequestItems bzw. RequestVariables genannt.

In DTML l��t sich der Inahlt des request einfach abfragen. Der Befehl:

bettet die aktuellen request-Daten in eine �bersichtlich formattierte HTML-Seite ein. Dies ist sehr n�tzlich, falls das Ergebnis einer Form-�bermittlung Schwierigkeiten bei der Interpretation macht.

-> Hier ist die aktuelle REQUESTAbfrageInDTML zum ausprobieren.

RequestItem Kategorien

Man kann 'REQUEST[key]?' verwenden um den Wert der mit key verkn�pft ist zu erhalten. Da jedoch HTTPRequest?-s komplex sind enthalten sie Bezeichner in mehreren Kategorien, die evtl. miteinander kollidieren. Da ist es manchmal hilfreich zu wissen, da� der REQUEST eine feinere Struktur hat, die einem erlaubt die verschiedenen Kategorien in kontrollierter Weise anzusprechen.

1 Explizit definierte RequestItem-s

Die Methode REQUEST gestattes es explizit RequestItems? zu definieren. Sie werden in einem MappingObject? zusammengefa�t. Diese Definitionen werden h�ufig eingesetzt, um eine Schw�che von DocumentTemplates? auszugleichen: Variablen, die ihren Wert als Folge des Rendern des Templates �ndern, werden nicht unterst�tzt. Explizit definierte RequestItems? werden als Ersatz f�r diese Variablen verwendet.

Auch aus Gr�nden der Performanz wird diese Abbildung verwendet: Um den Zugriff auf FormDaten? und COokies? zu erlauben. Wenn eine Bezeichnung im REQUEST aufgesucht wird, wird er effektiv gesucht, und es wird gepr�ft, ob er ein von Zope definierter Name oder ein HTTPHeader? ist, falls er dort nicht gefunden wird. Weil COokies? und FormDaten? ebenfalls �ber eine REQUEST-Suche zugreifbar sein sollen, werden sie w�hrend der Initialisierung zusammengebracht. Bei diesem "merge" haben die FormDaten? eine h�here Priorit�t als die CookieValues?.

1.2 FormDaten?

Die MemberForm? ist eine Abbildung mit allen vom ZPublisher festgelegten Argumenten. Normalerweise kommen diese Informationen von einer Einsendung von FormDaten?, daher der Name des members. Die Argumente k�nnen aber auch von einem explitziten QueryString? einer [URI]? herr�hren.

1.3 Cookies

Der UserAgent? schickt alle COOkies? die f�r den request relevant sein k�nnen in den HTTPHeader? COOKIE. ZPublisher vereinfacht die Nutzung indem er diesen header in die einzelnen cookies unterteilt und sie in einer weiteren Abbildung, dem MemberMapping? verf�gbar macht.

Der COOKIE header kann verschiedene cookies mit gleichem Namen enthalten. In diesem Fall erh�lt das cookie den ersten unter diesem Namen gefundenen Wert. Gem��? der CookieSpezifikation? ist dies der am meisten cookie-spezifische Wert mit gegebenem Bezeichner im RequestLocator?. (letzter Satz ist unverstaendlich, auch auf englisch! :(= ) - According to the cookie specification, this is the most specific cookie value with the given name available for the request locator.

1.4 Von Zope definierte RequestItems?.

Zope legt folgende items fest um die speziellen Aufgaben zu erleichtern:

REQUEST - Dies ist das eigentliche RequestObject?. Dies ist eine bequeme Definition f�r DocumentTemplates?. Sie haben direkten Zugriff auf die im RequestObject? definierten Bezeichnern. In manchen F�llen brauchen brauchen sie Zugriffsm�glichkeiten zum Objekt selber, also zB. um seine Methoden oder Members ansprechen zu k�nnen. Sie k�nnen dies mittels REQUEST.
RESPONSE - das ResponseObject?
PUBLISHED - das Objekt, das "ver�ffentlicht" (= vom Server ausgeliefert) werden soll. Dies ist das Objekt, da� w�hrend dem TRaversal? bestimmt und aufgerufen wurde, um die REsponse? zu erzeugen.
PARENTS - Eine Liste der Objekte, die w�hrend dem TRaversal? besucht und �berschritten wurden, ohne das PublisheObject? selber, in umgedrehter Reihenfolge. Dies bedeutet: 'PARENTS[0]?' ist das Objekt, da� vor dem published object besucht wurde; 'PARENTS[-1]?' ist das RootObject.
URL - Der RequestLocator? ohne QueryString?
URLn, URLPATHn - URLn? ist der Vorspann der [URL]? den man erh�lt, wenn man die letzten n PfadAbschnitte? wegstreicht. Dies bedeutet: [URL0]? hat den gleichen Wert wie [URL]?; [URL1]? ist [URL]? ohne den letzten PfadAbschnitt?, usw.
URLPATHn ist der Pfad-Bestandteil von URLn?.

Diese Variablen verwendet man h�ufig um absolute URLs? f�r Objekte in der Nachbarschaft zu erzeugen.

BASEn, BASEPATHn - Jedes BASEn? ist ein Vorspann von [URL]?. [BASE1]? ist die [URL]? des RootObjects? der Webseite. F�r n>=1 gilt: Jedes BASEn+1 erh�lt man, indem man zu BASEn den n�chsten PfadAbschnitt? hinzuf�gt. Wenn Zope mittels [CGI9 von einem anderen Webserver angesprochen wird, so ist '[BASE1]?' die URL des CGISkript?-s, '[BASE0]?' erh�lt man durch Streichen des letzten PfadAbschnitts?; in sonstigen F�llen haben '[BASE0]?' und '[BASE1]?' identischen Wert.
Each BASEn? is a prefix of URL. BASE1 is the URL of the Zope Web site's root object. For n>=1, each BASEn?+1 is obtained form BASEn? by adding the next path segment. If Zope is used via CGI from another Web server, then BASE1 is the URL of the CGI script and BASE0 is obtained from BASE1 by removing the last path segment; otherwise, BASE0 and BASE1 have identical values.
BASEPATHn ist der Pfad-Bestandteil von BASEn?.

Diese Variablen werden h�ufig verwendet um absloute URLs? zu erzeugen, die URLs? der Objekte die sich oben in der Hierarchie von Zope oder sogar �ber Zope befinden (falls Zope hinter einem anderen Webserver l�uft.)

[BODY]?, [BODYFILE]? - Der RequestBody? als String bzw. FileObject?.

1.5. Umgebungs-Daten

Umgebungsdaten wie zB HTTPHeader?, Server-Information und einige andere Informationen k�nnen im MemberEnviron?, einer weiteren Abbildung abgefragt werden. Viele dieser items werden vom [CGI]? (CommonGatewayInterface?) definiert, einschlie�lich die Informationen einiger HTTPHeader?. Die meisten HTTPHeader? sind mittels der Vorsilbe HTTP vor dem HTTPHeader?-Namen ansprechbar und mit - �bersetzt nach . Zum Beispiel kann auf den HTTPHEader? [USER-AGENT]? von Zope aus unter dem Namen [HTTP_USER_AGENT]? zugegriffen werden. Es gibt auch eine Methode [get_header]? mittels derer man den HTTPHeader? sowohl �ber seinen HTTP-Namen als auch �ber Zope's abgewandelte Form ansprechen kann.

Die meisten Anwednungen machen keinen Gebrauch dieser UmgebungsDaten?. Daher werden die Details hier erstmal ausgelassen.

2. VirtualHost?-Unterst�tzung

REQUEST stellt zwei Methoden bereit, au�erdem ein member f�r die Unterst�tzung von VirtualHost?.

Ein VirtualHost? ist ein Host, der sich wie ein gew�hnlicher Host verh�lt und so aussieht: Er hat seine eigene Berechtigung und scheinbar Zugriff auf die komplette Webseite. Tats�chlich ist er nur ein Teil des physikalischen Hosts und die Site des VirtualHost? ist nur ein SubTree? der kompletten Webseite. Diese Virtualisierungen erfordern ein bi�chen Magie. Speziell sind die physikalische Pfad im ZopeWesiteObject? nicht mehr l�nger identisch mit den logischen Pfaden, die von den Web requests benutzt werden. Dies d�rfte Zope verwirren wenn es ungen�gend �ber diese Virtualisierung informiert ist.

ZPublisher stellt den TraversalHook? (Aufh�nger) [__before_publishing_traverse__]? bereit. Dieser hook (Haken) kann verwendet werden um das meiste von Zope's "Magie der Virtualisierung" zu implementieren. Eine Grundvoraussetzung f�r VirtualHosting? ist die Umleitung (redirection) der REquests?, die am Zope root ankommen, zum jeweiligen root des VirtualHosts?. W�hrend des TRaversal? beh�lt REQUEST die PfadAbschnitte? die noch f�r die Traverse gebraucht werden, in seinem MemberPath?. Um den request an einen SubTree? umzuleiten kann der hook ganz einfach die ID des SubTree?'s an den Pfad anh�ngen. ZPublisher wird dann das richtige Objekt spezifisch zum VirtualHost? finden. Die weiteren RequestItems?, die Server und URLs? beschreiben, sind falsch solange sie nicht korrigiert werden. REQUEST bietet hier die Methoden [setServerURL]? und [setVirtualRoot]? um dies zu korrigieren.

Normalerweise verwendet man das SiteAccess?-Produkt um einen [__before_publishing_traverse__]? hook zu installieren. Auf http://zope.org gibt es einige HowTos?, die im Detail beschreiben wie VirtualHosting? mit SiteAccess? implementiert wird.

SiteAccess? kann au�er f�r VirtualHosting? auch f�r LocaliZation? und SessionManagement? dienen. Dies wird in der Beispielanwendung erkl�rt von Dieter erkl�rt.

In ZopePageTemplates Sprache kann dies auch geschrieben werden: