Zend_Controller_Router_Rewrite
is the standard
framework router. Routing is the process of taking a URI endpoint
(that part of the URI which comes after the base
URL) and decomposing it into parameters to determine which module,
controller, and action of that controller should receive the
request. This values of the module, controller, action and other
parameters are packaged into a
Zend_Controller_Request_Http
object which is then
processed by Zend_Controller_Dispatcher_Standard
.
Routing occurs only once: when the request is initially received and
before the first controller is dispatched.
Zend_Controller_Router_Rewrite
is designed to allow for
mod_rewrite-like functionality using pure PHP structures. It is very
loosely based on Ruby on Rails routing and does not require any
prior knowledge of webserver URL rewriting. It is designed to work
with a single Apache mod_rewrite rule (one of):
RewriteEngine on RewriteRule !\.(js|ico|gif|jpg|png|css|html)$ index.php
or (preferred):
RewriteEngine On RewriteCond %{REQUEST_FILENAME} -s [OR] RewriteCond %{REQUEST_FILENAME} -l [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^.*$ - [NC,L] RewriteRule ^.*$ index.php [NC,L]
The rewrite router can also be used with the IIS webserver (versions <= 7.0) if Isapi_Rewrite has been installed as an Isapi extension with the following rewrite rule:
RewriteRule ^[\w/\%]*(?:\.(?!(?:js|ico|gif|jpg|png|css|html)$)[\w\%]*$)? /index.php [I]
IIS Isapi_Rewrite
When using IIS, $_SERVER['REQUEST_URI']
will
either not exist, or be set as an empty string. In this case,
Zend_Controller_Request_Http
will attempt to use
the $_SERVER['HTTP_X_REWRITE_URL']
value set by the
Isapi_Rewrite
extension.
IIS 7.0 introduces a native URL rewriting module, and it can be configured as follows:
<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <rewrite> <rules> <rule name="Imported Rule 1" stopProcessing="true"> <match url="^.*$" /> <conditions logicalGrouping="MatchAny"> <add input="{REQUEST_FILENAME}" matchType="IsFile" pattern="" ignoreCase="false" /> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" pattern="" ignoreCase="false" /> </conditions> <action type="None" /> </rule> <rule name="Imported Rule 2" stopProcessing="true"> <match url="^.*$" /> <action type="Rewrite" url="index.php" /> </rule> </rules> </rewrite> </system.webServer> </configuration>
If using Lighttpd, the following rewrite rule is valid:
url.rewrite-once = ( ".*\?(.*)$" => "/index.php?$1", ".*\.(js|ico|gif|jpg|png|css|html)$" => "$0", "" => "/index.php" )
To properly use the rewrite router you have to instantiate it, add some user defined routes and inject it into the controller. The following code illustrates the procedure:
// Create a router $router = $ctrl->getRouter(); // returns a rewrite router by default $router->addRoute( 'user', new Zend_Controller_Router_Route('user/:username', array('controller' => 'user', 'action' => 'info')) );
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
Zend_Controller_Router_Route_Interface
. Eg.:
$router->addRoute('user', new Zend_Controller_Router_Route('user/:username'));
Rewrite Router comes with six 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 the Module route, which should rather be used once and probably as the most generic route (i.e., 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 (e.g., for URL generation purposes). The second parameter being the route itself.
Note
The most common use of the route name is through the means of
Zend_View
url helper:
<a href= "<?php echo $this->url(array('username' => 'martel'), 'user') ?>">Martel</a>
Which would result in the href: user/martel
.
Routing is a simple process of iterating through all provided routes
and matching its definitions to current request URI. When a positive
match is found, variable values are returned from the Route instance
and are injected into the Zend_Controller_Request
object for later use in the dispatcher as well as in user created
controllers. On a negative match result, the next route in the chain
is checked.
If you need to determine which route was matched, you can use the
getCurrentRouteName()
method, which will return the
identifier used when registering the route with the router. If you
want the actual route object, you can use
getCurrentRoute()
.
Reverse Matching
Routes are matched in reverse order so make sure your most generic routes are defined first.
Returned Values
Values returned from routing come from URL parameters or user
defined route defaults. These variables are later accessible
through the 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
The names of these special variables may be different if you
choose to alter the defaults in
Zend_Controller_Request_Http
by means of the
setControllerKey()
and
setActionKey()
methods.
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/news/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
(i.e., 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 (e.g.,
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 by using
Zend_Controller_Request_Http
and calling the
setBaseUrl()
method (see Base URL and Subdirectories):
$request->setBaseUrl('/~user/application-root/');
You can set global parameters in a router which are automatically
supplied to a route when assembling through
setGlobalParam()
. If a global parameter is set
but also given to the assemble method directly, the user parameter
overrides the global parameter. You can set a global parameter this
way:
$router->setGlobalParam('lang', 'en');
Zend_Controller_Router_Route
is the standard framework
route. It 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 the route for such
functionality could look like:
$route = new Zend_Controller_Router_Route( 'author/:username', array( 'controller' => 'profile', 'action' => 'userinfo' ) ); $router->addRoute('user', $route);
The first parameter in the Zend_Controller_Router_Route
constructor is a route definition that will be matched to a URL. Route
definitions consist of static and dynamic parts separated by the slash
('/') character. Static parts are just simple text:
author. Dynamic parts, called variables, are marked by
prepending a colon to the variable name: :username.
Character Usage
The current implementation allows you to use any character (except a slash) as a variable identifier, but it is strongly recommended that one uses only characters that are valid for PHP variable identifiers. Future implementations may alter this behaviour, 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 its
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
the following key and value pairs:
$values = array( 'username' => 'martel', 'controller' => 'profile', 'action' => 'userinfo' );
Later on, Zend_Controller_Dispatcher_Standard
should invoke
the userinfoAction()
method of your
ProfileController
class (in the default module) based on
these values. There you will be able to access all variables by means of
the 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 the default Module route (var => value pairs defined in the URI). The following route more-or-less mimics the Module route behavior:
$route = new Zend_Controller_Router_Route( ':module/:controller/:action/*', array('module' => 'default') ); $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);
The 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. Since no routing information is present (no controller and
action parameters are defined), the application will be dispatched
to the 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 the 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 the method
showAction()
of the class
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 a route defined like above, the router will match it only when
the year variable will contain numeric data, eg.
http://domain.com/archive/2345
. A URL like
http://example.com/archive/test
will not be matched and
control will be passed to the next route in the chain instead.
The standard route supports translated segments. To use this
feature, you have to define at least a translator (an instance
of Zend_Translate
) via one of the following ways:
-
Put it into the registry with the key
Zend_Translate
. -
Set it via the static method
Zend_Controller_Router_Route::setDefaultTranslator()
. -
Pass it as fourth parameter to the constructor.
By default, the locale specified in the Zend_Translate
instance will be used. To override it, you set it
(an instance of Zend_Locale
or a locale string) in one
of the following ways:
-
Put it into the registry with the key
Zend_Locale
. -
Set it via the static method
Zend_Controller_Router_Route::setDefaultLocale()
. -
Pass it as fifth parameter to the constructor.
-
Pass it as @locale parameter to the assemble method.
Translated segments are separated into two parts. Fixed segments are prefixed by a single @-sign, and will be translated to the current locale when assembling and reverted to the message ID when matching again. Dynamic segments are prefixed by :@. When assembling, the given parameter will be translated and inserted into the parameter position. When matching, the translated parameter from the URL will be reverted to the message ID again.
Message IDs and separate language file
Occasionally a message ID which you want to use in one of your routes is already used in a view script or somewhere else. To have full control over safe URLs, you should use a separate language file for the messages used in the route.
The following is the simplest way to prepare the standard route for translated segment usage:
// Prepare the translator $translator = new Zend_Translate( array( 'adapter' => 'array', 'content' => array(), 'locale' => 'en' ) ); $translator->addTranslation( array( 'content' => array( 'archive' => 'archiv', 'year' => 'jahr', 'month' => 'monat', 'index' => 'uebersicht' ), 'locale' => 'de' ) ); // Set the current locale for the translator $translator->setLocale('en'); // Set it as default translator for routes Zend_Controller_Router_Route::setDefaultTranslator($translator);
This example demonstrates the usage of static segments:
// Create the route $route = new Zend_Controller_Router_Route( '@archive', array( 'controller' => 'archive', 'action' => 'index' ) ); $router->addRoute('archive', $route); // Assemble the URL in default locale: archive $route->assemble(array()); // Assemble the URL in german: archiv $route->assemble(array());
You can use the dynamic segments to create a module-route like translated version:
// Create the route $route = new Zend_Controller_Router_Route( ':@controller/:@action/*', array( 'controller' => 'index', 'action' => 'index' ) ); $router->addRoute('archive', $route); // Assemble the URL in default locale: archive/index/foo/bar $route->assemble(array('controller' => 'archive', 'foo' => 'bar')); // Assemble the URL in german: archiv/uebersicht/foo/bar $route->assemble(array('controller' => 'archive', 'foo' => 'bar'));
You can also mix static and dynamic segments:
// Create the route $route = new Zend_Controller_Router_Route( '@archive/:@mode/:value', array( 'mode' => 'year' 'value' => 2005, 'controller' => 'archive', 'action' => 'show' ), array('mode' => '(month|year)' 'value' => '\d+') ); $router->addRoute('archive', $route); // Assemble the URL in default locale: archive/month/5 $route->assemble(array('mode' => 'month', 'value' => '5')); // Assemble the URL in german: archiv/monat/5 $route->assemble(array('mode' => 'month', 'value' => '5', '@locale' => 'de'));
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
, and dispatch to
AuthController::loginAction()
.
Warning: Static Routes must Contain Sane Defaults
Since a static route does not pass any part of the URL to the request object as parameters, you must pass all parameters necessary for dispatching a request as defaults to the route. Omitting the "controller" or "action" default values will have unexpected results, and will likely result in the request being undispatchable.
As a rule of thumb, always provide each of the following default values:
controller
action
module (if not default)
Optionally, you can also pass the "useDefaultControllerAlways" parameter to the front controller during bootstrapping:
$front->setParam('useDefaultControllerAlways', true);
However, this is considered a workaround; it is always better to explicitly define sane defaults.
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. At the same time, it should be faster than the standard Route.
Like the standard route, this route has to be initialized with a route definition and some defaults. Let's create an archive route as an example, similar to the previously defined one, only using the 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' );
Note
Leading and trailing slashes are trimmed from the URL in the Router
prior to a match. As a result, matching the URL
http://domain.com/foo/bar/
, would involve a regex of
foo/bar
, and not /foo/bar
.
Note
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, and you should match the entire string.
Note
This route class uses the '#' character for a delimiter. This means that you will need to escape hash characters ('#') but not forward slashes ('/') in your route definitions. Since the '#' character (named anchor) is rarely passed to the webserver, you will rarely need to use that character in your regex.
You can get the contents of the defined subpatterns the usual way:
public function showAction() { $request = $this->getRequest(); $year = $request->getParam(1); // $year = '2006'; }
Note
Notice the key is an integer (1) instead of a string ('1').
This route will not yet work exactly the same as its standard route counterpart since the default for 'year' is not yet set. And what may not yet be evident is that we will have a problem with a trailing slash even if we declare a 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( 1 => '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. This parameter is an associative array that 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 either direction to make it work in any environment. Keys may contain variable names or subpattern indexes:
$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) );
Note
Subpattern keys have to be represented by integers.
Notice that the numeric index in Request values is now gone and a named variable is shown in its 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. As an example, the
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 patterns are not easily reversed, you will need to prepare
a reverse URL if you wish to use a 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 the Regex route,
you ask? Primarily, it allows you to 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
,
and have it decompose the last path element,
01-Using_the_Regex_Router.html
, into an article ID and
article title or description; this is not possible with the standard route.
With the Regex route, you can do something like the following 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);
As you can see, this adds a tremendous amount of flexibility over the standard route.
Zend_Controller_Router_Route_Hostname
is the hostname route of
the framework. It works similar to the standard route, but it works on
the with the hostname of the called URL instead with the path.
Let's use the example from the standard route and see how it would look
like in a hostname based way. Instead of calling the user via a path,
we'd want to have a user to be able to call
http://martel.users.example.com
to see the information
about the user "martel":
$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));
The first parameter in the Zend_Controller_Router_Route_Hostname
constructor is a route definition that will be matched to a hostname. Route
definitions consist of static and dynamic parts separated by the dot
('.') character. Dynamic parts, called variables, are marked by
prepending a colon to the variable name: :username.
Static parts are just simple text: user.
Hostname routes can, but never should be used as is. The reason behind
that is, that a hostname route alone would match any path. So what you
have to do is to chain a path route to the hostname route. This is done
like in the example by calling $hostnameRoute->chain($pathRoute);.
By doing this, $hostnameRoute
isn't modified, but a new
route (Zend_Controller_Router_Route_Chain
) is returned,
which can then be given to the router.
Zend_Controller_Router_Route_Chain
is a route which allows
to chain multiple routes together. This allows you to chain
hostname-routes and path routes, or multiple path routes for example.
Chaining can be done either programatically or within a configuration
file.
Parameter Priority
When chaining routes together, the parameters of the outer route have a higher priority than the parameters of the inner route. Thus if you define a controller in the outer and in the inner route, the controller of the outer route will be selected.
When chaining programatically, there are two ways to achieve this. The
first one is to create a new
Zend_Controller_Router_Route_Chain
instance and then
calling the chain()
method multiple times with all routes
which should be chained together. The other way is to take the first
route, e.g. a hostname route, and calling the chain()
method on it with the route which should be appended to it. This
will not modify the hostname route, but return a new instance of
Zend_Controller_Router_Route_Chain
, which then has both
routes chained together:
// Create two routes $hostnameRoute = new Zend_Controller_Router_Route_Hostname(...); $pathRoute = new Zend_Controller_Router_Route(...); // First way, chain them via the chain route $chainedRoute = new Zend_Controller_Router_Route_Chain(); $chainedRoute->chain($hostnameRoute) ->chain($pathRoute); // Second way, chain them directly $chainedRoute = $hostnameRoute->chain($pathRoute);
When chaining routes together, their separator is a slash by default. There may be cases when you want to have a different separator:
// Create two routes $firstRoute = new Zend_Controller_Router_Route('foo'); $secondRoute = new Zend_Controller_Router_Route('bar'); // Chain them together with a different separator $chainedRoute = $firstRoute->chain($secondRoute, '-'); // Assemble the route: "foo-bar" echo $chainedRoute->assemble();
To chain routes together in a config file, there are additional parameters for the configuration of those. The simpler approach is to use the chains parameters. This one is simply a list of routes, which will be chained with the parent route. Neither the parent- nor the child-route will be added directly to the router but only the resulting chained route. The name of the chained route in the router will be the parent route name and the child route name concatenated with a dash (-) by default. A simple config in XML would look like this:
<routes> <www type="Zend_Controller_Router_Route_Hostname"> <route>www.example.com</route> <chains> <language type="Zend_Controller_Router_Route"> <route>:language</route> <reqs language="[a-z]{2}"> <chains> <index type="Zend_Controller_Router_Route_Static"> <route></route> <defaults module="default" controller="index" action="index" /> </index> <imprint type="Zend_Controller_Router_Route_Static"> <route>imprint</route> <defaults module="default" controller="index" action="index" /> </imprint> </chains> </language> </chains> </www> <users type="Zend_Controller_Router_Route_Hostname"> <route>users.example.com</route> <chains> <profile type="Zend_Controller_Router_Route"> <route>:username</route> <defaults module="users" controller="profile" action="index" /> </profile> </chains> </users> <misc type="Zend_Controller_Router_Route_Static"> <route>misc</route> </misc> </routes>
This will result in the three routes www-language-index, www-language-imprint and users-language-profile which will only match based on the hostname and the route misc, which will match with any hostname.
The alternative way of creating a chained route is via the chain parameter, which can only be used with the chain-route type directly, and also just works in the root level:
<routes> <www type="Zend_Controller_Router_Route_Chain"> <route>www.example.com</route> </www> <language type="Zend_Controller_Router_Route"> <route>:language</route> <reqs language="[a-z]{2}"> </language> <index type="Zend_Controller_Router_Route_Static"> <route></route> <defaults module="default" controller="index" action="index" /> </index> <imprint type="Zend_Controller_Router_Route_Static"> <route>imprint</route> <defaults module="default" controller="index" action="index" /> </imprint> <www-index type="Zend_Controller_Router_Route_Chain"> <chain>www, language, index</chain> </www-index> <www-imprint type="Zend_Controller_Router_Route_Chain"> <chain>www, language, imprint</chain> </www-imprint> </routes>
You can also give the chain parameter as array instead of separating the routes with a comma:
<routes> <www-index type="Zend_Controller_Router_Route_Chain"> <chain>www</chain> <chain>language</chain> <chain>index</chain> </www-index> <www-imprint type="Zend_Controller_Router_Route_Chain"> <chain>www</chain> <chain>language</chain> <chain>imprint</chain> </www-imprint> </routes>
When you configure chain routes with Zend_Config
and
want the chain name separator to be different from a dash, you
need to specify this separator separately:
$config = new Zend_Config(array( 'chainName' => array( 'type' => 'Zend_Controller_Router_Route_Static', 'route' => 'foo', 'chains' => array( 'subRouteName' => array( 'type' => 'Zend_Controller_Router_Route_Static', 'route' => 'bar', 'defaults' => array( 'module' => 'module', 'controller' => 'controller', 'action' => 'action' ) ) ) ) )); // Set separator before adding config $router->setChainNameSeparator('_separator_') // Add config $router->addConfig($config); // The name of our route now is: chainName_separator_subRouteName echo $this->_router->assemble(array(), 'chainName_separator_subRouteName'); // The proof: it echoes /foo/bar
The Zend_Rest
component contains a RESTful route
for Zend_Controller_Router_Rewrite
. This route
offers a standardized routing scheme that routes requests by translating
the HTTP method and the URI
to a module, controller, and action. The table below provides an overview
of how request methods and URI's are routed.
Table 42. Zend_Rest_Route Behavior
Method | URI | Module_Controller::action |
---|---|---|
GET |
/product/ratings/ |
Product_RatingsController::indexAction() |
GET |
/product/ratings/:id |
Product_RatingsController::getAction() |
POST |
/product/ratings |
Product_RatingsController::postAction() |
PUT |
/product/ratings/:id |
Product_RatingsController::putAction() |
DELETE |
/product/ratings/:id |
Product_RatingsController::deleteAction()
|
POST |
/product/ratings/:id?_method=PUT |
Product_RatingsController::putAction() |
POST |
/product/ratings/:id?_method=DELETE |
Product_RatingsController::deleteAction()
|
To enable Zend_Rest_Route
for an entire
application, construct it with no config params and add it as the
default route on the front controller:
$front = Zend_Controller_Front::getInstance(); $restRoute = new Zend_Rest_Route($front); $front->getRouter()->addRoute('default', $restRoute);
Note
If Zend_Rest_Route
cannot match a valid
module, controller, or action, it will return FALSE
and the
router will attempt to match using the next route in the router.
To enable Zend_Rest_Route
for specific modules,
construct it with an array of module names as the 3rd constructor argument:
$front = Zend_Controller_Front::getInstance(); $restRoute = new Zend_Rest_Route($front, array(), array('product')); $front->getRouter()->addRoute('rest', $restRoute);
To enable Zend_Rest_Route
for specific
controllers, add an array of controller names as the value of each module array element.
$front = Zend_Controller_Front::getInstance(); $restRoute = new Zend_Rest_Route($front, array(), array( 'product' => array('ratings') )); $front->getRouter()->addRoute('rest', $restRoute);
To use Zend_Rest_Route
from an INI config
file, use a route type parameter and set the config options:
routes.rest.type = Zend_Rest_Route routes.rest.defaults.controller = object routes.rest.mod = project,user
The 'type' option designates the RESTful routing config type. The 'defaults' option is
used to specify custom default module, controller, and/or actions for the route. All
other options in the config group are treated as RESTful module names, and their values
are RESTful controller names. The example config defines
Mod_ProjectController
and
Mod_UserController
as RESTful controllers.
Then use the addConfig()
method of the Rewrite router object:
$config = new Zend_Config_Ini('path/to/routes.ini'); $router = new Zend_Controller_Router_Rewrite(); $router->addConfig($config, 'routes');
To help or guide development of Controllers for use with
Zend_Rest_Route
, extend your Controllers from
Zend_Rest_Controller
.
Zend_Rest_Controller
defines the 5 most-commonly
needed operations for RESTful resources in the form of abstract action
methods.
-
indexAction()
- Should retrieve an index of resources and assign it to view. -
getAction()
- Should retrieve a single resource identified by URI and assign it to view. -
postAction()
- Should accept a new single resource and persist its state. -
putAction()
- Should accept a single resource idenitifed by URI and persist its state. -
deleteAction()
- Should delete a single resource identified by URI.
Sometimes it is more convenient to update a configuration file with
new routes than to change the code. This is possible via the
addConfig()
method. Basically, you create a
Zend_Config
-compatible configuration, and in your code read it in
and pass it to the RewriteRouter.
As an example, consider the following INI file:
[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
The above INI file can then be read into a
Zend_Config
object as follows:
$config = new Zend_Config_Ini('/path/to/config.ini', 'production'); $router = new Zend_Controller_Router_Rewrite(); $router->addConfig($config, 'routes');
In the above example, we tell the router to use the 'routes' section
of the INI file to use for its routes. Each first-level key under
that section will be used to define a route name; the above example
defines the routes 'archive' and 'news'. Each route then requires,
at minimum, a 'route' entry and one or more 'defaults' entries;
optionally one or more 'reqs' (short for 'required') may be
provided. All told, these correspond to the three arguments provided
to a Zend_Controller_Router_Route_Interface
object. An
option key, 'type', can be used to specify the route class type to
use for that particular route; by default, it uses
Zend_Controller_Router_Route
. In the example above, the
'news' route is defined to use
Zend_Controller_Router_Route_Static
.
The standard rewrite router should provide most functionality you may need; most often, you will only need to create a new route type in order to provide new or modified functionality over the provided routes.
That said, you may at some point find yourself wanting to use a
different routing paradigm. The interface
Zend_Controller_Router_Interface
provides the minimal
information required to create a router, and consists of a single
method.
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); }
Routing only occurs once: when the request is first received into the system. The purpose of the router is to determine the controller, action, and optional parameters based on the request environment, and then set them in the request. The request object is then passed to the dispatcher. If it is not possible to map a route to a dispatch token, the router should do nothing to the request object.