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:

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.

Note: 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:

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:

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:

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:

Above route will match a URL of http://domain.com/login, and dispatch to AuthController::loginAction().

Note: 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:

1. $front->setParam('useDefaultControllerAlways'

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:

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:

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:

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:

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:

This will result in following values injected into Request:

The map may be defined in either direction to make it work in any environment. Keys may contain variable names or subpattern indexes:

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:

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:

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:

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:

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":

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.

Note: 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:

When chaining routes together, their separator is a slash by default. There may be cases when you want to have a different separator:

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.

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()