Zend_Controller_Router_Route_Regex 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: '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: '2006', 'controller' => 'archive', 'action' => 'show' ); ]]> 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. 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. 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: getRequest(); $year = $request->getParam(1); // $year = '2006'; } ]]> 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: '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: 'archive', 'action' => 'show' ), array( 1 => 'year' ) ); $router->addRoute('archive', $route); ]]> This will result in following values injected into Request: '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: 'year') ); // OR $route = new Zend_Controller_Router_Route_Regex( 'archive/(\d+)', array( ... ), array('year' => 1) ); ]]> 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: 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: '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: 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: '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.