Das Zend Framework stellt verschiedene Alternativen zu den bereit gestellten Standardklassen zur Verfügung. Dies beinhaltet alternative Request Objekte, Router und Response Objekte.
Zend_Controller_Request_Http
stellt ein Request Objekt für die
Verwendung in einer HTTP Umgebung bereit. Zend_Controller_Request_Http
ist die Standard Request Klasse, die von Zend_Controller_Dispatcher
verwendet wird.
Zend_Controller_Request_Http
kapselt den Zugriff auf relevante Werte
wie der Schlüssel und Wert für Controller und Action Variablen des Routers und alle
zusätzlichen Parameter, die aus der URI ermittelt wurden. Durch den Proxy zu
Zend_Controller_Request_Http
erlaubt es zusätzlich den Zugriff auf
superglobale Werte als öffentliche Eigenschaften und verwaltet die aktuelle Basis
URL und Request URI. Superglobale Werte können in einem Request Objekt nicht
gesetzt werden, stattdessen verwendet man die setParam/getParam Methoden um
Benutzerparameter zu setzen oder zu erhalten.
Superglobale Daten | |
---|---|
Beim Zugriff auf superglobale Daten über die öffentlichen Eigenschaften von
|
Auf spezifische superglobale Werte kann alternativ über eine öffentliche Methode
zugegriffen werden. Zum Beispiel kann auf den unverarbeitete Wert von
$_POST['user']
durch Aufruf der getPost('user')
Methode
des Request Objekts zugegriffen werden.
Zend_Controller_Request_Http
erlaubt, dass Zend_Controller_Router_Rewrite
in einem Unterverzeichnis verwendet werden kann. Zend_Controller_Request_Http
versucht, die Basis URL automatisch zu erkennen und entsprechend zu setzen.
Wenn man zum Beispiel seine index.php
in einem Webserverunterverzeichnis
mit Namen /projects/myapp/index.php
verwendet, sollte die Basis URL
(die Rewrite Basis) auf /projects/myapp
gesetzt werden. Dieser String
wird dann vom Anfang des Pfades entfernt, bevor irgend welche Routingtreffer
ermittelt werden. Dies befreit einem davon, es an den Anfang jeder Route setzen zu
müssen. Eine Route 'user/:username'
passt auf URIs wie
http://localhost/projects/myapp/user/martel
und
http://example.com/user/martel
.
URL Erkennung beachtet Groß- und Kleinschreibung | |
---|---|
Die automatische Erkennung der Basis URL beachtet die Groß- und Kleinschreibung, weshalb man sicherstellen sollte, dass die URL einem Unterverzeichnis im Dateisystem entspricht (sogar auf einem Windows Rechner). Andernfalls wird auf die noRoute aktion umgeleitet. |
Sollte die Basis URL falsch erkannt werden, kann man diese auch mit einem eigenen
Pfad mit Hilfe der setBaseUrl()
Methode der
Zend_Controller_Request_Http
Klasse oder der
Zend_Controller_Front
Klasse überschreiben. Die einfachste Methode ist
die von Zend_Controller_Front
, welche es an das Request Object weiter
leitet. Beispiel, um eine eigene Basis URL zu setzen:
/** * Dispatch Request with custom base URL with Zend_Controller_Front. */ $router = new Zend_Controller_Router_Rewrite(); $controller = Zend_Controller_Front::getInstance(); $controller->setControllerDirectory('./application/controllers') ->setRouter($router) ->setBaseUrl('/projects/myapp'); // set the base url! $response = $controller->dispatch();
Zend_Controller_Router_Rewrite
ist der Standard Router des Frameworks.
Routing ist der Prozess der Übernahme und Zerteilung einer URI, um zu
ermitteln, welcher Controller und welche Aktion des Controllers die Anfrage
erhalten soll. Die Definition 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)$ index.php
oder:
RewriteEngine on RewriteCond %{SCRIPT_FILENAME} !-f RewriteCond %{SCRIPT_FILENAME} !-d RewriteRule ^(.*)$ index.php/$1
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)$)[\w\%]*$)? /index.php [I]
IIS Isapi_Rewrite | |
---|---|
Bei Verwenung von IIS, wird |
Bei der verwendung von Lighttpd, ist folgende Umschreibungsregel gültig:
url.rewrite-once = ( ".*\.(js|ico|gif|jpg|png|css)$" => "$0", "" => "/index.php")
Um den Rewrite Router richtig zu verwenden, mußt du ihn instanziieren, einige benutzerdefinierte Routen hinzufügen und in den Controller einbinden. Der folgende Code veranschaulicht die Vorgehensweise:
/* Erstelle einen Router */ $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')) ); </sect3> <sect3 id="zend.controller.providedsubclasses.rewriterouter.basic"> <title>Basic Rewrite Router operation</title> <para> The heart of the RewriteRouter is the definition of user defined routes. Routes are added by calling the addRoute method of RewriteRouter and passing in a new instance of a class implementing <code>Zend_Controller_Router_Route_Interface</code>. Eg.: </para> <programlisting role="php"><![CDATA[ $router->addRoute('user', new Zend_Controller_Router_Route('user/:username'));
Rewrite Router comes with four basic types of routes (one of which is special):
Routes may be used numerous times to create a chain or user defined application routing schema. You may use any number of routes in any configuration, with the exception of Module route which should rather be used once and probably as the most generic route (ie. as a default). Each route will be described in greater detail later on.
The first parameter to addRoute is the name of the route. It is used as a handle for getting the routes out of the router, eg. for URL generation purposes. The second parameter being the route itself.
Anmerkung | |
---|---|
The most common use of the route name is through the means of Zend_View url helper: <a href="<?= $this->url('user', array('username' => 'martel')) ?>">Martel</a>
Which would result in href of: |
Routing is a simple process of iterating through all provided routes and matching it's definitions to current request URI. When a positive match is found, variable values are returned from the Route instance and are injected into Zend_Controller_Request object for later use in dispatcher as well as in user created controllers. On a negative match next route in chain is checked.
Reverse matching | |
---|---|
Routes are matched in reverse order so make sure your most generic routes are defined first. |
Returned values | |
---|---|
Values which are returned from routing come from URL parameters or user defined route defaults. These variables are later accessible through a Zend_Controller_Request::getParam or Zend_Controller_Action::_getParam methods. |
There are three special variables which can be used in your routes - 'module', 'controller' and 'action'. These special variables are used by Zend_Controller_Dispatcher to find a controller and action to dispatch to.
Special variables | |
---|---|
Names of these special variables may be different if you choose to
alter the defaults in |
Zend_Controller_Router_Rewrite comes preconfigured with a default route,
which will match URIs in the shape of controller/action
.
Additionally, a module name may be specified as the first path
element, allowing URIs of the form module/controller/action
.
Finally, it will also match any additional parameters appended
to the URI by default - controller/action/var1/value1/var2/value2
.
Some examples of how such routes are matched:
// Assuming the following: $ctrl->setControllerDirectory( array( 'default' => '/path/to/default/controllers', 'news' => '/path/to/blog/controllers', 'blog' => '/path/to/blog/controllers' ) ); Module only: http://example/news module == news Invalid module maps to controller name: http://example/foo controller == foo Module + controller: http://example/blog/archive module == blog controller == archive Module + controller + action: http://example/blog/archive/list module == blog controller == archive action == list Module + controller + action + params: http://example/blog/archive/list/sort/alpha/date/desc module == blog controller == archive action == list sort == alpha date == desc
The default route is simply a Zend_Controller_Router_Route_Module
object stored under the name (index) of 'default' in RewriteRouter. It's created more-or-less
like below:
$compat = new Zend_Controller_Router_Route_Module(array(), $dispatcher, $request); $this->addRoute('default', $compat);
If you do not want this particular default route in your routing schema, you
may override it by creating your own 'default' route (ie. storing
it under the name of 'default') or removing it altogether by using
removeDefaultRoutes()
:
// Remove any default routes $router->removeDefaultRoutes();
The rewrite router can be used in subdirectories (eg.
http://domain.com/~user/application-root/
>) in which case the base
URL of the application (/~user/application-root
) should be
automatically detected by Zend_Controller_Request_Http
and
used accordingly.
Should the base URL be detected incorrectly you can override it
with your own base path with the help of Zend_Controller_Request_Http
by calling the setBaseUrl()
method (see Abschnitt 7.4.2.3, „Basis Url und Unterverzeichnisse“):
$request->setBaseUrl(/~user/application-root/);
Zend_Controller_Router_Route
is a standard framework route which
combines ease of use with flexible route definition. Each route consists primarily
of URL mapping (of static and dynamic parts (variables)) and may be initialized
with defaults as well as with variable requirements.
Let's imagine our fictional application will need some informational page
about the content authors. We want to be able to point our web browsers to
http://domain.com/author/martel
to see the information
about this "martel" guy. And route for such functionality could look like:
$route = new Zend_Controller_Router_Route( 'author/:username', array('controller' => 'profile', 'action' => 'userinfo') ); $router->addRoute('user', $route);
First parameter in the
Zend_Controller_Router_Route
constructor is a route definition that will be matched to a URL.
Route definition consists of static and dynamic parts
separated by the slash ('/') character. Dynamic parts, called variables,
are marked by the colon prepended to the variable name
(eg. :username
). Static parts are just a simple text (eg. author
).
Character usage | |
---|---|
Current implementation allows you to use any characters (except a slash) as a variable identifier but it is strongly recommended that one uses only php variable friendly characters. Implementation may be altered in the future which could result in hidden bugs in your code. |
This example route should be matched when you point your browser to
'http://domain.com/author/martel'
in which case all it's
variables will be injected to the Zend_Controller_Request
object
and will be accessible in your ProfileController. Variables returned by
this example may be represented as an array of following key
and value pairs:
$values = array( 'username' => 'martel', 'controller' => 'profile', 'action' => 'userinfo' );
Later on Zend_Controller_Dispatcher
should invoke userinfoAction
method of your ProfileController class (in default module) based on these
values. There you will be able to access all variables by the means of
Zend_Controller_Action::_getParam or Zend_Controller_Request::getParam methods:
public function userinfoAction() { $request = $this->getRequest(); $username = $request->getParam('username'); $username = $this->_getParam('username'); }
Route definition can contain one more special character - a wildcard - represented by '*' symbol. It is used to gather parameters similarly to Module route (var => value pairs defined in the URI). Following route mimicks Module route behavior:
$route = new Zend_Controller_Router_Route(':controller/:action/*'); $router->addRoute('default', $route);
Every variable in the route can have a default and this is what the second
parameter of the Zend_Controller_Router_Route
constructor
is used for. This parameter is an array with keys representing variable
names and with values as desired defaults:
$route = new Zend_Controller_Router_Route( 'archive/:year', array( 'year' => 2006 ) ); $router->addRoute('archive', $route);
Above route will match URLs like 'http://domain.com/archive/2005'
and
'http://example.com/archive'
. In the latter case the variable
year will have an initial default value of 2006.
This example will result in injecting a year variable to the request object.
And since no routing information is present (no controller and
action parameters are defined) application will be dispatched to default controller
and action method (which are both defined in Zend_Controller_Dispatcher_Abstract
).
To make it more usable you have to provide a valid controller and
a valid action as route's defaults:
$route = new Zend_Controller_Router_Route( 'archive/:year', array( 'year' => 2006, 'controller' => 'archive', 'action' => 'show' ) ); $router->addRoute('archive', $route);
This route will then result in dispatching to showAction of ArchiveController.
One can add a third parameter to the Zend_Controller_Router_Route
constructor where variable requirements may be set. These are defined
as parts of a regular expression:
$route = new Zend_Controller_Router_Route( 'archive/:year', array( 'year' => 2006, 'controller' => 'archive', 'action' => 'show' ), array('year' => '\d+') ); $router->addRoute('archive', $route);
With route defined like above, Rewrite Router will match it
only when the year variable will contain numeric data, eg.
http://domain.com/archive/2345
. URL of
http://example.com/archive/test
will not be matched
and control will be passed to the next route in chain instead.
The examples above all use dynamic routes -- routes that contain patterns to match against. Sometimes, however, a particular route is set in stone, and firing up the regular expression engine would be an overkill. The answer to this situation is to use static routes:
$route = new Zend_Controller_Router_Route_Static( 'login', array('controller' => 'auth', 'action' => 'login') ); $router->addRoute('login', $route);
Above route will match a URL of http://domain.com/login
In addition to the default and static route types, a Regular Expression route type is available. This route offers more power and flexibility over the others, but at a slight cost of complexity. And should be faster than a standard Route at the same time.
As well as the standard route, this route has to be initialized with route definition and some defaults. Let's create an archive route as an example, similar to the previoulsy defined one, only using Regex route this time:
$route = new Zend_Controller_Router_Route_Regex( 'archive/(\d+)', array( 'controller' => 'archive', 'action' => 'show' ) ); $router->addRoute('archive', $route);
Every defined regex subpattern will be injected
to the request object. With our above example, after successful matching
http://domain.com/archive/2006
, the resulting value array
may look like:
$values = array( 1 => '2006', 'controller' => 'archive', 'action' => 'show' );
Anmerkung | |
---|---|
Leading and trailing slashes are trimmed from the URL in the Router
prior to a match. As a result, matching the URL |
Anmerkung | |
---|---|
Line start and line end anchors ('^' and '$', respectively) are automatically pre- and appended to all expressions. Thus, you should not use these in your regular expressions. |
Anmerkung | |
---|---|
This route class uses the |
You can get the contents of the defined subpatterns the usual way:
public function showAction() { $request = $this->getRequest(); $year = $request->getParam(1); // $year = '2006'; }
Anmerkung | |
---|---|
Notice the key is an integer (1) instead of a string ('1'). |
This route will not yet work exactly the same as it's standard route counterpart since the default for 'year' is not yet set. And what may not yet be evident we will have a problem with a trailing slash even if we declare default for the year and make the subpattern optional. The solution is to make the whole year part optional along with the slash but catch only the numeric part:
$route = new Zend_Controller_Router_Route_Regex( 'archive(?:/(\d+))?', array( 'year' => '2006', 'controller' => 'archive', 'action' => 'show' ) ); $router->addRoute('archive', $route);
Now let's get to the problem you have probably noticed on your own by now. Using integer based keys for parameters is not an easily manageable solution and may be potentially problematic in the long run. And that's where the third parameter comes in. One which represents a map of regex subpatterns to parameter named keys. Let's work on our easier example:
$route = new Zend_Controller_Router_Route_Regex( 'archive/(\d+)', array( 'controller' => 'archive', 'action' => 'show' ), array( 1 => 'year' ) ); $router->addRoute('archive', $route);
This will result in following values injected into Request:
$values = array( 'year' => '2006', 'controller' => 'archive', 'action' => 'show' );
The map may be defined in both ways to make it work in any environment (eg. Zend_Config). Keys may contain variable names or subpattern numbers.
Anmerkung | |
---|---|
Subpattern keys have to be represented by integers |
$route = new Zend_Controller_Router_Route_Regex( 'archive/(\d+)', array( ... ), array( 1 => 'year' ) ); // OR $route = new Zend_Controller_Router_Route_Regex( 'archive/(\d+)', array( ... ), array( 'year' => 1 ) );
Notice that the numeric index in Request values is now gone and a named variable is shown in it's place. Of course you can mix numeric and named variables if you wish:
$route = new Zend_Controller_Router_Route_Regex( 'archive/(\d+)/page/(\d+)', array( ... ), array( 'year' => 1 ) );
Which will result in mixed values available in the Request.
Example URL http://domain.com/archive/2006/page/10
will result in following values:
$values = array( 'year' => '2006', 2 => 10, 'controller' => 'archive', 'action' => 'show' );
Since regex is not easily reversed, you will need to prepare reverse URL if you wish to use an url helper or even an assemble method of this class. This reversed path is represented by a string parsable by sprintf() and is defined as a fourth construct parameter:
$route = new Zend_Controller_Router_Route_Regex( 'archive/(\d+)', array( ... ), array( 'year' => 1 ), 'archive/%s' );
All of this is something which was already possible by the means of
a standard route object, so where's the benefit in using Regex Route, you ask?
You can describe any type of URL without any restrictions.
Imagine you have a blog and wish to create URLs like:
http://domain.com/blog/archive/01-Using_the_Regex_Router.html
.
Now that's something which was not possible before, is it? Here's the solution:
$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);
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.
Zend_Controller_Response_Http
ist ein Response Objekt, das für die
Verwendung in einer HTTP Umgebung geeignet ist. Es enthält Methoden für das Setzen,
Erhalten und Entfernen von Headern und die __toString()
Methode sendet
alle Header auf einmal bevor die Reponse Inhalte zurückgegeben werden.
setHeader()
nimmt zwei Argumente entgegen, einen Header Typ und den
Header Wert. Ein dritter, optionaler Parameter (wenn übergeben und true) erzwingt das
Überschreiben des vorhandenen Headers gleichen Typs mit dem neuen Header.