Previous Next

Der Standard Router

Einführung

Zend_Controller_Router_Rewrite ist der Standard Router des Frameworks. Routing ist der Prozess der Übernahme und Zerteilung einer URI, um zu ermitteln, welches Modul, welcher Controller und welche Aktion des Controllers die Anfrage erhalten soll. Die Definition des Moduls, des Controllers, der Aktion sowie weiterer Parameter wird in einem Objekt mit Namen Zend_Controller_Dispatcher_Token gekapselt, das dann vom Zend_Controller_Dispatcher_Standard verarbeitet wird. Das Routing geschieht nur einmal: wenn zu Beginn die Anfrage erhalten wird und bevor der erste Controller aufgerufen wird.

Zend_Controller_Router_Rewrite wurde entwickelt, um mit reinen PHP Strukturen eine mod_rewrite ähnliche Funktionalität zu erlauben. Es richtet sich sehr frei nach dem Ruby on Rails Routing und benötigt kein tieferes Wissen über URL Weiterleitung des Webservers. Es wurde entwickelt, um mit einer einzigen mod_rewrite Regel zu arbeiten.

RewriteEngine on
RewriteRule !\.(js|ico|gif|jpg|png|css|html)$ index.php

oder (bevorzugt):

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

Der Rewrite Router kann auch mit dem IIS Webserver verwendet werden, wenn » Isapi_Rewrite als Isapi Erweiterung installiert wurde und folgende Umschreibungsregel verwendet wird:

RewriteRule ^[\w/\%]*(?:\.(?!(?:js|ico|gif|jpg|png|css|html)$)[\w\%]*$)? /index.php [I]

Note: IIS Isapi_Rewrite

Bei Verwendung von IIS, wird $_SERVER['REQUEST_URI'] entweder nicht vorhanden oder auf einen leeren String gesetzt sein. In diesem Fall wird Zend_Controller_Request_Http versuchen, den durch die Isapi_Rewrite Erweiterung gesetzten Wert $_SERVER['HTTP_X_REWRITE_URL'] zu verwenden.

Bei der Verwendung von Lighttpd, ist folgende Umschreibungsregel gültig:

url.rewrite-once = (
    ".*\?(.*)$" => "/index.php?$1",
    ".*\.(js|ico|gif|jpg|png|css|html)$" => "$0",
    "" => "/index.php"
)

Einen Router verwenden

Um den Rewrite Router richtig zu verwenden, muß er instanziiert, einige benutzerdefinierte Routen hinzufügt und in den Controller einbunden werden. Der folgende Code veranschaulicht die Vorgehensweise:

// Einen Router erstellen

$router = $ctrl->getRouter(); // gibt standardmäßig einen Rewrite Router zurück
$router->addRoute(
    'user',
    new Zend_Controller_Router_Route('user/:username',
                                     array('controller' => 'user',
                                           'action' => 'info'))
);

Grundsätzliche Rewrite Router Operationen

Das Herz des RewriteRouters ist die Definition von Benutzerdefinierten Routen. Routen werden durch aufruf der addRoute Methode des RewriteRouters hinzugefügt und übergeben eine neue Instanz einer Klasse die Zend_Controller_Router_Route_Interface implementiert. Z.B.:

$router->addRoute('user',
                  new Zend_Controller_Router_Route('user/:username'));

Der Rewrite Router kommt mit fünf Basistypen von Routen (eine von denen ist speziell): is special):

Routen können unzählige Male verwendet werden um eine Kette oder benutzerdefinierte Routing Schemas von Anwendungen zu erstellen. Es kann jede beliebige Anzahl von Routen in jeder beliebigen Konfiguration verwendet werden, mit Ausnahme der Modul Route, welche nur einmal verwendet werden sollte, und möglicherweise die am meisten standardmäßige Route ist (z.B., als ein Standard). Jede Route wird später detailiert beschrieben.

Der erste Parameter für addRoute ist der Name der Route. Er wird als Handle verwendet um die Route außerhalb des Routers zu erhalten (z.B. für den Zweck der URL Erzeugung). Der zweite Parameter ist die Route selbst.

Note:

Die gewöhnlichste Verwendung des Namens der Route ist gegeben durch die Zwecke des Zend_View Url Helfers:

Martel

Was zu folgender href führt: user/martel.

Routen ist ein einfacher Prozess des Durchlaufens aller vorhandenen Routen und Vergleichens deren Definitionen mit der aktuellen Anfrage URI. Wenn ein positiver Vergleich gefunden wird, werden variable Werte von der Instanz des Routers zurückgegeben, und werden für die spätere Verwendung im Dispatcher in das Zend_Controller_Request Objekt iniziiert, sowie in von Benutzern erstellten Controllern. Bei einem negativen Ergebnis des Vergleiches, wird die nächste Route in der Kette geprüft.

Note: Umgekehrter Vergleich

Routen werden in umgekehrter Reihenfolge verglichen. Deswegen muß sichergestellt werden das die generellen Routen zuerst definiert werden.

Note: Zurückgegebene Werte

Werte die vom Routen zurückgegeben werden kommen von URL Parametern oder Benutzerdefinierten Router Standards. Diese Variablen sind später durch die Zend_Controller_Request::getParam() oder Zend_Controller_Action::_getParam()Methoden verwendbar.

Es gibt drei spezielle Variablen welche in den Routen verwendet werden können - 'module', 'controller' und 'action'. Diese speziellen Variablen werden durch Zend_Controller_Dispatcher verwendet um einen Kontroller und die Aktion zu funden zu der verwiesen wird.

Note: Spezielle Variablen

Die Namen dieser speziellen Variablen kann unterschiedlich sein wenn entschieden wird die Standards in Zend_Controller_Request_Http mithilfe der setControllerKey und setActionKey Methode zu Ändern.

Standard Routen

Zend_Controller_Router_Rewrite kommt mit einer Standard Route vorkonfiguriert, welche URIs im Sinn von controller/action entspricht. Zusätzlich kann ein Modul Name als erstes Pfad Element definiert werden, welches URIs in der Form von module/controller/action erlaubt. Letztendlich wird es auch allen zusätzlichen Parametern entsprechen die der URI standardmäßig hinzugefügt wurden - controller/action/var1/value1/var2/value2.

Einige Beispiele wie solche Routen verglichen werden:

// Folgende Annahme:
$ctrl->setControllerDirectory(
    array(
        'default' => '/path/to/default/controllers',
        'news'    => '/path/to/news/controllers',
        'blog'    => '/path/to/blog/controllers'
    )
);

Nur Modul:
http://example/news
    module == news

Ungültiges Modul, geht an den Controller Namen:
http://example/foo
    controller == foo

Modul + Controller:
http://example/blog/archive
    module     == blog
    controller == archive

Modul + Controller + Aktion:
http://example/blog/archive/list
    module     == blog
    controller == archive
    action     == list

Modul + Controller + Aktion + Parameter:
http://example/blog/archive/list/sort/alpha/date/desc
    module     == blog
    controller == archive
    action     == list
    sort       == alpha
    date       == desc

Die Standardroute ist einfach ein Zend_Controller_Router_Route_Module Objekt welches unter dem Namen (Index) 'default' im RewriteRouter gespeichert ist. Es wird mehr oder weniger wie folgt erstellt:

$compat = new Zend_Controller_Router_Route_Module(array(),
                                                  $dispatcher,
                                                  $request);
$this->addRoute('default', $compat);

Wenn diese spezielle Standard Route im eigenen Routing Schema nicht gewünscht ist, kann Sie durch Erstellung einer eigenen 'default' Route überschrieben werden (z.B. durch Speichern unter dem Namen 'default') oder dem kompletten Entfernen durch verwenden von removeDefaultRoutes():

// Löschen aller Standard Routen
$router->removeDefaultRoutes();

Basis URL und Unterverzeichnisse

Der Rewrite Router kann in Unterverzeichnissen verwendet werden (z.B. http://domain.com/~user/application-root/) und in diesem Fall sollte die Basis URL der Anwendung (/~user/application-root) automatisch durch Zend_Controller_Request_Http erkannt und auch verwendet werden.

Sollte die Basis URL nicht richtig erkannt werden kann diese mit eigenen Basispfad überschrieben werden durch Verwendung von Zend_Controller_Request_Http und Auruf der setBaseUrl() Methode (siehe Basis Url und Unterverzeichnisse):

$request->setBaseUrl('/~user/application-root/');

Globale Parameter

Man kann in einem Router globale Parameter setzen die der Route automatisch zur Verfügung stehen wenn Sie durch setGlobalParam eingefügt werden. Wenn ein globaler Parameter gesetzt ist, aber auch direkt an die Assemble Methode gegeben wird, überschreibt der Benutzer-Parameter den Globalen-Parameter. Globale Parameter können auf folgendem Weg gesetzt werden:

$router->setGlobalParam('lang', 'en');

Router Typen

Zend_Controller_Router_Route

Zend_Controller_Router_Route ist die standardmäßige Framework Route. Sie kombiniert einfache Verwendung mit einer flexiblen Routendefinition. Jede Route besteht primär aus URL Übereinstimmungen (von statischen und dynamischen Teilen (Variablen)) und kann mit Standardwerten initialisiert werden wie auch mit variablen Notwendigkeiten.

Angenommen unsere fiktive Anwendung benötigt eine informelle Seite über den Seitenauthor. Es soll möglich sein mit dem Browser auf http://domain.com/author/martel zu verweisen um die Informationen über diesen "martel" Typ zu sehen. Und die Route für so eine Funktionalität würde so aussehen:

$route = new Zend_Controller_Router_Route(
    'author/:username',
    array(
        'controller' => 'profile',
        'action'     => 'userinfo'
    )
);

$router->addRoute('user', $route);

Der ersten Parameter im Konstruktor von http://domain.com/author/martel ist eine Routendefinition die einer URL entspricht. Routendefinitionen bestehen aus statischen und dynamischen Teilen die durch einen Schrägstrich ('/') seperiert sind. Statische Teile sind nur einfacher Text: author. Dynamische Teile, Variablen genannt, werden durch einen vorangestellten Doppelpunkt, zum variablen Namen, markiert: :username.

Note: Zeichen verwenden

Die aktuelle Implementation erlaubt die Verwendung von allen Zeichen (außer einem Schrägstrich) als variablen Identifikator, aber es wird dringend empfohlen das nur Zeichen verwendet werden die auch für PHP Veriablen Identifikatoren gültig sind. Zukünftige Implementationen können dieses Verhlaten ändern, was zu versteckten Bugs im eigenen Code führen würde.

Diese Beispielroute wird verglichen wenn der Browser auf http://domain.com/author/martel zeigt. In diesem Fall werden alle seine Variablen dem Zend_Controller_Request Objekt injiziiert und es kann im ProfileController darauf zugegriffen werden. Variablen die von diesem Beispiel zurückgegeben werden können als Array mit den folgenden Schlüssel- und Wertepaaren repräsentiert werden:

$values = array(
    'username'   => 'martel',
    'controller' => 'profile',
    'action'     => 'userinfo'
);

Später sollte Zend_Controller_Dispatcher_Standard die userinfoAction() Methode der eigenen ProfileController Klasse aufrufen (im Standardmodul) basierend auf diesen Werten. Dort ist es möglich alle Variablen durch die Zend_Controller_Action::_getParam() oder Zend_Controller_Request::getParam() Methoden zuzugreifen:

public function userinfoAction()
{
    $request = $this->getRequest();
    $username = $request->getParam('username');

    $username = $this->_getParam('username');
}

Eine Routendefinition kann ein weiteres spezielles Zeichen enthalten - eine Wildcard - dargestellt durch ein '*' Symbol. Es wird verwendet um Parameter genauso wie im standard Modulrouter zu erhalten (var => Wertepaare definiert in der URI). Die folgende Route imitiert mehr oder weniger das Verhalten des Modulrouters:

$route = new Zend_Controller_Router_Route(
    ':module/:controller/:action/*',
    array('module' => 'default')
);
$router->addRoute('default', $route);

Variable Standards

Jede Variable im Router kann einen Standardwert haben und das ist für was der zweite Parameter des Konstruktors von Zend_Controller_Router_Route verwendet wird. Dieser Parameter ist ein Array mit Schlüsseln die Variablennamen repräsentieren und mit Werten als gewünschte Standards:

$route = new Zend_Controller_Router_Route(
    'archive/:year',
    array('year' => 2006)
);
$router->addRoute('archive', $route);

Die obige Route entspricht URLs wie http://domain.com/archive/2005 und http://example.com/archive. Im späteren Fall wird die Variable year einen initialen Standardwert von 2006 haben.

Dieses Beispiel resultiert darin das eine year Variable in das Anfrage Objekt injiziiert wird. Da keine Routinginformation vorhanden ist (es sind keine Kontroller und Aktionsparameter definiert), wird die Anwendung zum Standardkontroller und der Aktionsmethode (welche beide in Zend_Controller_Dispatcher_Abstract definiert sind) weitergeleitet. Um es verwendbarer zu machen muß ein gültiger Kontroller und eine gültige aktion als Standard für die Route angegeben werden:

$route = new Zend_Controller_Router_Route(
    'archive/:year',
    array(
        'year'       => 2006,
        'controller' => 'archive',
        'action'     => 'show'
    )
);
$router->addRoute('archive', $route);

Diese Route führt dazu das an die Methode showAction() der Klasse ArchiveController weitergeleitet wird.

Variable Anforderungen

Man kann einen dritten Parameter dem Zend_Controller_Router_Route Konstruktor hinzufügen wo variable Anforderungen gesetzt werden können. Diese werden als Teil eines regulären Ausdrucks definiert:

$route = new Zend_Controller_Router_Route(
    'archive/:year',
    array(
        'year'       => 2006,
        'controller' => 'archive',
        'action'     => 'show'
    ),
    array('year' => '\d+')
);
$router->addRoute('archive', $route);

Mit einer Route die wie oben definiert ist, wird der Router nur dann stattfinden wenn die year Variable nummerische Daten enthält, z.B. http://domain.com/archive/2345. Eine URL wie http://example.com/archive/test wird nicht zugeordnet und die Kontrolle wird stattdessen an die nächste Route in der Kette übertragen.

Zend_Controller_Router_Route_Static

Die oben angeführten Beispiele verwenden alle dynamische Routen -- Routen die einem Pattern entsprechen. Trotzdem wird manchmal eine spezielle Route in Stein gegossen, und das Starten der Regular Expression Maschine wäre ein Overkill. Die Lösung zu dieser Situation ist die Verwendung von statischen Routen:

$route = new Zend_Controller_Router_Route_Static(
    'login',
    array('controller' => 'auth', 'action' => 'login')
);
$router->addRoute('login', $route);

Die obige Route passt zu einer URL von http://domain.com/login, und leitet weiter zu AuthController::loginAction().

Zend_Controller_Router_Route_Regex

Zusätzlich zu den standard statischen Routetypen, ist ein Regular Expression Routetyp vorhanden. Diese Route bietet mehr Power und Flexibilität als die anderen, aber auf leichten Kosten von Komplexität. Wärend der selben Zeit, sollte Sie schneller als die Standardroute sein.

Wie die Standardroute, muß diese Route mit einer Routendefinition und einigen Standardwerten initialisiert werden. Lasst uns eine Archivroute als Beispiel erstellen, ähnlich der zuletzt definierten, nur das dieses Mal die Regex Route verwendet wird:

$route = new Zend_Controller_Router_Route_Regex(
    'archive/(\d+)',
    array(
        'controller' => 'archive',
        'action'     => 'show'
    )
);
$router->addRoute('archive', $route);

Jedes definierte Regex Subpattern wird in das Anfrageobjekt injiziiert. Mit dem obigen Beispiel, nachdem http://domain.com/archive/2006 erfolgreich geprüft wurde, kann das resultierende Wertearray so aussehen:

$values = array(
    1            => '2006',
    'controller' => 'archive',
    'action'     => 'show'
);

Note:

Führende und folgende Schrägstriche werden von der URL im Router vor dem Vergleich entfernt. Als Ergebnis, wird ein Vergleich der URL http://domain.com/foo/bar/, ein Regex von foo/bar inkludieren, aber nicht /foo/bar.

Note:

Zeilenbeginn und Endanker (normalerweise '^' und '$') werden automatisch allen Ausdrücken vor- und nachgesetzt. Deswegen sollten Sie nicht in den Regular Expressions verwendet werden, und der komplette String sollte entsprechen.

Note:

Diese Routeklasse verwendet das # Zeichen als Begrenzer. Das bedeutet das ein Hashzeichen ('#') kommentiert werden muß aber keine Schrägstriche ('/') in der Routendefinition. Da das '#' Zeichen (Anker genannt) selben an einen Webserver übergeben wird, wird man dieses Zeichen selten in der eigenen regex verwenden.

Die Inhalte von definierten Subpattern können auf dem üblichen Weg bekommen werden:

public function showAction()
{
    $request = $this->getRequest();
    $year    = $request->getParam(1); // $year = '2006';
}

Note:

Beachte das der Schlüssel ein Integer ist (1) anstatt ein String ('1').

Diese Route wird jetzt noch nicht exakt gleich wie Ihr Gegenspieler, die Standardroute, arbeiten da der Standard für 'year' noch nicht gesetzt ist. Und was jetzt noch nicht offensichtlich ist, ist das wir ein Problem mit endenden Schrägstrichen haben, selbst wenn wir einen Standard für das Jahr definieren und das Subpattern optional machen. Die Lösung ist, den ganzen year Teil optional zu nachen zusammen mit dem Schrägstrich, aber nur den nummerischen Teil zu holen:

$route = new Zend_Controller_Router_Route_Regex(
    'archive(?:/(\d+))?',
    array(
        1            => '2006',
        'controller' => 'archive',
        'action'     => 'show'
    )
);
$router->addRoute('archive', $route);

Jetzt betrachten wir das Problem das möglicherweise schon selbst gefunden wurde. Die Verwendung von Integer basierten Schlüsseln für Parameter ist keine einfach zu handhabende Lösung und kann, wärend einer langen Laufzeit, potentiell problematisch sein. Hier kommt der dritte Parameter ins Spiel. Dieser Parameter ist ein assoziatives Array das einer Karte von Regex Subpatterns zu Parametern benannten Schlüsseln entspricht. Betrachten wir ein einfacheres Beispiel:

$route = new Zend_Controller_Router_Route_Regex(
    'archive/(\d+)',
    array(
        'controller' => 'archive',
        'action' => 'show'
    ),
    array(
        1 => 'year'
    )
);
$router->addRoute('archive', $route);

Als Ergebnis werden die folgenden Werte in die Anfrage injiziiert:

$values = array(
    'year'       => '2006',
    'controller' => 'archive',
    'action'     => 'show'
);

Die Karte kann in jede Richtung definiert werden damit Sie in jeder Umgebung funktioniert. Schlüssel können Variablennamen oder Indezes von Subpattern enthalten:

$route = new Zend_Controller_Router_Route_Regex(
    'archive/(\d+)',
    array( ... ),
    array(1 => 'year')
);

// ODER

$route = new Zend_Controller_Router_Route_Regex(
    'archive/(\d+)',
    array( ... ),
    array('year' => 1)
);

Note:

Schlüssel von Subpattern müssen durch Integer repräsentiert werden.

Es gilt zu beachten das der nummerische Index in den Anfragewerten jetzt weg ist und eine benannte Variable statt Ihm angezeigt wird. Natürlich können nummerische und benannte Variablen gemischt werden wenn das gewünscht ist:

$route = new Zend_Controller_Router_Route_Regex(
    'archive/(\d+)/page/(\d+)',
    array( ... ),
    array('year' => 1)
);

Das führt zu gemischten Werten die in der Anfrage vorhanden sind. Als Beispiel, wird die URL http://domain.com/archive/2006/page/10 zu folgenden Werte führen:

$values = array(
    'year'       => '2006',
    2            => 10,
    'controller' => 'archive',
    'action'     => 'show'
);

Da Regex Patterns nicht einfach rückgängig zu machen sind, muß eine umgekehrte URL vorbereitet werden wenn ein URL Helfer verwendet werden soll oder sogar eine Herstellungsmethode dieser Klasse. Dieser umgekehrte Pfad wird durch einen String dargestellt der durch sprintf() durchsucht werden kann und als vierter Parameter definiert wird:

$route = new Zend_Controller_Router_Route_Regex(
    'archive/(\d+)',
    array( ... ),
    array('year' => 1),
    'archive/%s'
);

Da all das bereits etwas ist das durch die Bedeutung eines standardmäßigen Route Objektes möglich ist kommt natürlich die Frage aus worin der Vorteil einer regex Route besteht? Primär erlaubt Sie jeden Typ von URL zu beschreiben ohne irgendwelche Einschränkungen. Angenommen man hat einen Blog und will eine URL wie die folgende erstellen: http://domain.com/blog/archive/01-Using_the_Regex_Router.html, und muß das jetzt Pfad Element 01-Using_the_Regex_Router.html bearbeiten, in eine Artikel ID und eine Artikel Titel/Beschreibung; das ist nicht möglich mit der Standardroute. Mit der Regex Route ist etwas wie die folgende Lösung möglich:

$route = new Zend_Controller_Router_Route_Regex(
    'blog/archive/(\d+)-(.+)\.html',
    array(
        'controller' => 'blog',
        'action'     => 'view'
    ),
    array(
        1 => 'id',
        2 => 'description'
    ),
    'blog/archive/%d-%s.html'
);
$router->addRoute('blogArchive', $route);

Wie man sieht, fügt das ein enormes Potential von Flexibilität zur Stnadardroute hinzu.

Zend_Controller_Router_Route_Hostname

Zend_Controller_Router_Route_Hostname ist die Hostname Route des Frameworks. Sie arbeitet ähnlich wie die Standardrouten, aber Sie arbeitet an und mit dem Hostnamen der aufgerufenen URL statt mit dem Pfad.

Verwenden wir also ein Beispiel von der Standardroute und schauen wir uns an wie Sie auf einem Hostnamen basierenden Weg aussehen würde. Statt das der Benutzer über einen Pfad aufgerufen wird, wollen wir das der Benutzer http://martel.users.example.com aufrufen kann, um die Informationen über den Benutzer "martel" zu sehen:

$hostnameRoute = new Zend_Controller_Router_Route_Hostname(
    ':username.users.example.com',
    array(
        'controller' => 'profile',
        'action'     => 'userinfo'
    )
);

$plainPathRoute = new Zend_Controller_Router_Route_Static('');

$router->addRoute('user', $hostnameRoute->chain($plainPathRoute);

Der erste Parameter in Konstruktor von Zend_Controller_Router_Route_Hostname ist eine Routerdefinition die zu einem Hostnamen passt. Routerdefinitionen bestehen aus statischen und dynamischen Teilen die durch ein Punkt ('.') Zeichen getrennt sind. Dynamische Teile, genannt Variablen, werden durch einen, dem Variablennamen vorangestellten Doppelpunkt, gekennzeichnet: :username. Statische Teile sind nur einfacher Text: user.

Hostnamerouten können verwendet werden wie sie sind, sollten es aber nie. Der Grund dahinter ist, das Hostnamerouten alleine jedem Pfad entsprechen würden. Was man also tun muß, ist eine Pfadroute an die Hostnameroute zu ketten. Das wird, wie im Beispiel, getan indem $hostnameRoute->chain($pathRoute); aufgerufen wird. Indem das getan wird, wird $hostnameRoute nicht geändert, aber eine neue Route (Zend_Controller_Router_Route_Chain), welche dann dem Router übergeben werden kann, wird zurückgegeben.

Note: Priorität der Parameter

Wenn Routen wie die Hostnameroute und die Pfadroute zusammengekettet werden, haben die Parameter der Hostnameroute eine höhere Priorität als die Parameter der Pfadroute. Deshalb wird, wenn man im Hostnamen und in der Pfadroute einen Kontroller definiert, der Kontroller der Hostnameroute ausgewählt.

Hostnamerouten über Zend_Config

Um Hostnamerouten und Pfadrouten zu verknüpfen gibt es einen zusätzlichen Parameter für die Konfiguration der chains heißt. Das ist einfach eine Liste von Routen, welche mit der Elternkette verknüpft werden. Weder die Eltern-, noch die Kindkette werden direkt dem Router hinzugefügt, sondern nur die verkettete Route. Der Name der verketteten Route im Router ist der Name der Elternroute und der Name der Kindrote verknüpft mit einem Bindestrich (-). Eine einfache Konfiguration in XML würde so aussehen:


    
        www.example.com
        
            
                
                
            
            
                imprint
                
            
        
    
    
        users.example.com
        
            
                :username
                
            
        
    
    
        misc
    

Das führt zu den drei Routen www-index, www-imprint und users-profile welche nur anhand des Hostnamens und der Route misc entsprechen, welche bei jedem Hostnamen passt.

Zend_Config mit dem RewriteRouter verwenden

Manchmal ist es praktischer, eine Konfigurationsdatei mit neuen Routen zu aktualisieren, als den Code zu ändern. Dies ist mit Hilfe der addConfig() Methode möglich. Im Wesentlichen kann man eine Zend_Config kompatible Konfiguration erstellen, in seinem Code einlesen und an den RewriteRouter übergeben:

Als Beispiel wird die folgende INI Datei angenommen:

[production]
routes.archive.route = "archive/:year/*"
routes.archive.defaults.controller = archive
routes.archive.defaults.action = show
routes.archive.defaults.year = 2000
routes.archive.reqs.year = "\d+"

routes.news.type = "Zend_Controller_Router_Route_Static"
routes.news.route = "news"
routes.news.defaults.controller = "news"
routes.news.defaults.action = "list"

routes.archive.type = "Zend_Controller_Router_Route_Regex"
routes.archive.route = "archive/(\d+)"
routes.archive.defaults.controller = "archive"
routes.archive.defaults.action = "show"
routes.archive.map.1 = "year"
; OR: routes.archive.map.year = 1

Die oben angeführte INI Datei kann dann wie folgt in ein Zend_Config Objekt eingelesen werden:

$config = new Zend_Config_Ini('/path/to/config.ini', 'production');
$router = new Zend_Controller_Router_Rewrite();
$router->addConfig($config, 'routes');

Im oberen Beispiel teilen wir dem Router mit, den 'routes' Bereich der INI Datei für seine Routen zu verwenden. Jeder Schlüssel auf erster Ebene in diesem Bereich wird verwendet, um den Namen der Routen zu definieren; das obige Beispiel definiert die Routen 'archive' und 'news'. Jede Route erfordert dann mindestens einen 'route' Eintrag und einen oder mehrere 'defaults' Einträge; optional können eine oder mehrere 'reqs' (kurz für 'required', d.h. erforderlich) Einträge angegeben werden. Alles in allem entspricht dies den drei Argumenten, die an ein Zend_Controller_Router_Route_Interface Objekt übergeben werden. Ein Optionsschlüssel 'type' kann verwendet werden, um den Typ der Routenklasse für diese Route anzugeben; standardmäßig wird Zend_Controller_Router_Route verwendet. Im obigen Beispiel wird die 'news' Route definiert, um Zend_Controller_Router_Route_Static zu verwenden.

Erben vom Router

Der Standard Rewrite Router sollte die meisten Funktionalitäten die benötigt werden zur Verfügung stellen; meistens wird es nur notwendig sein einen neuen Router Typen zu erstellen um neue oder modifizierte Funktionalitäten für die verfügbaren Routen zu bieten.

So gesehen, wird man in einigen Fällen ein anderes Routing Paradigma verwenden wollen. Das Interface Zend_Controller_Router_Interface bietet die minimalen Information die benötigt werden um einen Router er erstellen und besteht aus einer einzigen Methode.

interface Zend_Controller_Router_Interface
{
  /**
   * @param  Zend_Controller_Request_Abstract $request
   * @throws Zend_Controller_Router_Exception
   * @return Zend_Controller_Request_Abstract
   */
  public function route(Zend_Controller_Request_Abstract $request);
}

Das Routing findet nur einmal statt, wenn die Anfrage das erste Mal vom System erhalten wird. Der Zweck des Routers ist es, Controller, Aktion und optionale Parameter auf Basis der Anfrageumgebung zu ermitteln und im Request zu setzen. Das Request Objekt wird dann an den Dispatcher übergeben. Wenn es nicht möglich ist, eine Route auf einen Dispatch Token abzubilden, soll der Router nichts mit dem Request Objekt machen.

Previous Next
Introduction to Zend Framework
Übersicht
Installation
Zend_Acl
Einführung
Verfeinern der Zugriffskontrolle
Fortgeschrittene Verwendung
Zend_Amf
Einführung
Zend_Amf_Server
Zend_Auth
Einführung
Datenbanktabellen Authentifizierung
Digest Authentication
HTTP Authentication Adapter
LDAP Authentifizierung
Open ID Authentifikation
Zend_Cache
Einführung
Die Theorie des Cachens
Zend_Cache Frontends
Zend_Cache Backends
Zend_Captcha
Einführung
Captcha Anwendung
Captcha Adapter
Zend_Config
Einleitung
Theory of Operation
Zend_Config_Ini
Zend_Config_Xml
Zend_Config_Writer
Zend_Config_Writer
Zend_Console_Getopt
Einführung in Getopt
Definieren von Getopt Regeln
Holen von Optionen und Argumenten
Konfigurieren von Zend_Console_Getopt
Zend_Controller
Zend_Controller Schnellstart
Zend_Controller Grundlagen
Der Front Controller
Das Request Objekt
Der Standard Router
Der Dispatcher
Action Kontroller
Action Helfer
Das Response Objekt
Plugins
Eine konventionelle modulare Verzeichnis Struktur verwenden
MVC Ausnahmen
Migration von vorhergehenden Versionen
Zend_Currency
Einführung in Zend_Currency
Arbeiten mit Währungen
Migration von vorhergehenden Versionen
Zend_Date
Einführung
Theorie der Arbeitsweise
Basis Methoden
Zend_Date API Übersicht
Erstellen von Datumswerten
Konstanten für generelle Datums Funktionen
Funktionierende Beispiele
Zend_Db
Zend_Db_Adapter
Zend_Db_Statement
Zend_Db_Profiler
Zend_Db_Select
Zend_Db_Table
Zend_Db_Table_Row
Zend_Db_Table_Rowset
Zend_Db_Table Relationships
Zend_Debug
Variablen ausgeben
Zend_Dojo
Einführung
Zend_Dojo_Data: dojo.data Envelopes
Dojo View Helfer
Dojo Form Elemente und Dekoratore
Zend_Dom
Einführung
Zend_Dom_Query
Zend_Exception
Verwenden von Ausnahmen
Zend_Feed
Einführung
Feeds importieren
Feeds von Websites abrufen
Einen RSS Feed konsumieren
Einen Atom Feed konsumieren
Einen einzelnen Atom Eintrag konsumieren
Verändern der Feed- und Eintragsstruktur
Eigene Klassen für Feeds und Einträge
Zend_File
Zend_File_Transfer
Prüfungen für Zend_File_Transfer
Filter für Zend_File_Transfer
Migration von vorhergehenden Versionen
Zend_Filter
Einführung
Standard Filter Klassen
Filter Ketten
Filter schreiben
Zend_Filter_Input
Zend_Filter_Inflector
Zend_Form
Zend_Form
Schnellstart mit Zend_Form
Erstellen von Form Elementen mit Hilfe von Zend_Form_Element
Erstellen von Form durch Verwendung von Zend_Form
Erstellen von eigenem Form Markup durch Zend_Form_Decorator
Standard Form Elemente die mit dem With Zend Framework ausgeliefert werden
Standard Form Dekoratore die mit dem Zend Framework ausgeliefert werden
Internationalisierung von Zend_Form
Fortgeschrittene Verwendung von Zend_Form
Zend_Gdata
Einführung zu Gdata
Authentifizierung mit AuthSub
Die Buchsuche Daten API verwenden
Authentifizieren mit ClientLogin
Google Kalender verwenden
Verwenden der Google Dokumente Listen Daten API
Using Google Health
Google Tabellenkalkulation verwenden
Google Apps Provisionierung verwenden
Google Base verwenden
Picasa Web Alben verwenden
Verwenden der YouTube Daten API
Gdata Ausnahmen auffangen
Zend_Http
Zend_Http_Client - Einführung
Zend_Http_Client - Fortgeschrittende Nutzung
Zend_Http_Client - Verbindungsadapter
Zend_Http_Cookie und Zend_Http_CookieJar
Zend_Http_Response
Zend_InfoCard
Einführung
Zend_Json
Einführung
Grundlegende Verwendung
JSON Objects
XML zu JSON Konvertierung
Zend_Json_Server - JSON-RPC server
Zend_Layout
Einführung
Zend_Layout Schnellstart
Zend_Layout Konfigurations Optionen
Erweiterte Verwendung von Zend_Layout
Zend_Ldap
Einleitung
Zend_Loader
Dynamisches Laden von Dateien und Klassen
Plugins laden
Zend_Locale
Einführung
Zend_Locale verwenden
Normalisierung und Lokalisierung
Arbeiten mit Daten und Zeiten
Unterstützte Gebietsschemata
Migrieren von vorhergehenden Versionen
Zend_Log
Übersicht
Writer
Formatter
Filter
Zend_Mail
Einführung
Versand über SMTP
Versand von mehreren E-Mails über eine SMTP Verbindung
Verwendung von unterschiedlichen Versandwegen
HTML E-Mail
Anhänge
Empfänger hinzufügen
Die MIME Abgrenzung kontrollieren
Zusätzliche Kopfzeilen
Zeichensätze
Kodierung
SMTP Authentifizierung
SMTP Übertragungen sichern
Lesen von Mail Nachrichten
Zend_Measure
Einführung
Erstellung einer Maßeinheit
Ausgabe von Maßeinheiten
Manipulation von Maßeinheiten
Arten von Maßeinheiten
Zend_Memory
Übersicht
Memory Manager
Memory Objekte
Zend_Mime
Zend_Mime
Zend_Mime_Message
Zend_Mime_Part
Zend_OpenId
Einführung
Zend_OpenId_Consumer Grundlagen
Zend_OpenId_Provider
Zend_Paginator
Einführung
Verwendung
Konfiguration
Advanced usage
Zend_Pdf
Einführung
Erstellen und Laden von PDF Dokumenten
Änderungen von PDF Dokumenten speichern
Dokument Seiten
Zeichnen
Dokument Informationen und Metadaten
Anwendungsbeispiel für die Zend_Pdf Komponente
Zend_ProgressBar
Zend_ProgressBar
Zend_Registry
Die Registry verwenden
Zend_Rest
Einführung
Zend_Rest_Client
Zend_Rest_Server
Zend_Search_Lucene
Überblick
Indexerstellung
Einen Index durchsuchen
Abfragesprache
Abfrage Erzeugungs API
Zeichensätze
Erweiterbarkeit
Zusammenarbeit Mit Java Lucene
Erweitert
Die besten Anwendungen
Zend_Server
Einführung
Zend_Server_Reflection
Zend_Service
Einführung
Zend_Service_Akismet
Zend_Service_Amazon
Zend_Service_Audioscrobbler
Zend_Service_Delicious
Zend_Service_Flickr
Zend_Service_Nirvanix
Zend_Service_ReCaptcha
Zend_Service_Simpy
Einführung
Zend_Service_StrikeIron
Zend_Service_StrikeIron: Mitgelieferte Services
Zend_Service_StrikeIron: Erweiterte Verwendung
Zend_Service_Technorati
Zend_Service_Twitter
Zend_Service_Yahoo
Zend_Session
Einführung
Grundsätzliche Verwendung
Fortgeschrittene Benutzung
Globales Session Management
Zend_Session_SaveHandler_DbTable
Zend_Soap
Zend_Soap_Server
Zend_Soap_Client
WSDL Zugriffsmethoden
AutoDiscovery
Zend_Test
Einführung
Zend_Test_PHPUnit
Zend_Text
Zend_Text_Figlet
Zend_Text_Table
Zend_TimeSync
Einführung
Arbeiten mit Zend_TimeSync
Zend_Translate
Einführung
Adapter für Zend_Translate
Benutzen von Übersetzungs Adaptoren
Migration von vorhergehenden Versionen
Zend_Uri
Zend_Uri
Zend_Validate
Einführung
Standard Prüfklassen
Kettenprüfungen
Schreiben von Prüfern
Zend_Version
Auslesen der Version des Zend Frameworks
Zend_View
Einführung
Controller Skripte
View Scripte
View Helfer
Zend_View_Abstract
Zend_Wildfire
Zend_Wildfire
Zend_XmlRpc
Einführung
Zend_XmlRpc_Client
Zend_XmlRpc_Server
Zend Framework Voraussetzungen
PHP Version
PHP Erweiterungen
Zend Framework Komponenten
Zend Framework Abhängigkeiten
Zend Framework Coding Standard für PHP
Übersicht
PHP Dateiformatierung
Namens Konventionen
Code Stil
Zend Framework Performance Guide
Einführung
Laden von Klassen
Internationalisierung (I18n) und Lokalisierung (L10n)
Darstellen der View
Urheberrecht Informationen