Manipulate your Web site URLs any way you please using the Zend Framework's powerful custom routing feature.
Cleanly constructed (also known as "pretty") URLs are native to any Zend Framework-powered application, meaning you don't have to deal with ugly URL rewriting tasks or other programmatic voodoo to implement this convenient feature. Instead, the Zend Framework constructs these URLs naturally as you build out the project's controllers and respective actions.
As an example, if you were creating a new corporate site for a client and the client desired a page that listed available products, you logically might create an action named list hosted within a controller named Products. The resulting URL might look like this:
http://www.example.com/products/list/
The Zend Framework can also gracefully pass and retrieve parameters via the URL, allowing you to dynamically modify how the action behaves. For instance, you might tweak the list action's default behavior by passing along a category, which will result in the action displaying only those products that fall under the provided category:
Within the action, you can easily determine whether the category parameter has been passed and modify the action's behavior accordingly:
if ($this->_hasParam('category'))
{
$this->_getParam('category');
}
You possible can pass along more than one parameter. For instance, a highly structured catalog might organize products according to categories and subcategories, like this:
Like the previous example, you can retrieve these parameters using the $this->_getParam() method.
These examples really only touch the surface of what's possible using the Zend Framework's routing feature. By creating custom routes, you're free to construct routes in innumerable ways, assigning default parameter values, using regular expressions, and overriding controller and action names along the way.
Creating a Custom Route
To create a custom route you'll use the framework's Zend_Controller_Router_Route constructor to define the route alongside its associated controller, action, and parameters. You're free to create as many custom routes as necessary, although I recommend carefully considering what routes you absolutely need before adding them to your project, as these route lists have a tendency to grow rapidly. The typical place to place these routes is in your project's Bootstrap.php file. For instance, to create a custom route that will redirect users who navigate to www.example.com/login to the accounts controller's login method, update your Bootstrap.php file so it looks like this:
<?php
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
public function _initRoutes()
{
$frontController = Zend_Controller_Front::getInstance();
$router = $frontController->getRouter();
$route = new Zend_Controller_Router_Route_Static (
'login',
array('controller' => 'accounts',
'action' => 'login')
);
$router->addRoute('login', $route);
}
}
In this example, we're passing two parameters into the Zend_Controller_Router_Route_Static constructor. The first is the URL path as it looks in the browser. There's no need to include the domain name; just begin with the first part of the path following the domain. So in this case, we begin with login because the goal is to allow users to construct a URL that looks like www.example.com/login. The second parameter is an array defining where the user should be redirected to when the defined URL path is accessed (in this case, the accounts controller's login action).
As you accumulate additional custom routes, you can just define them one after another within the _initRoutes() method. Just be sure to assign a unique name to each route when adding it to the routing chain via the addRoute method.
Assigning Variable Defaults
The previous example involved a custom static route, which is to say a route that simply maps a defined origin with a defined destination. It's also possible to configure routes which are dynamically created based on the URL variation. Returning to the earlier catalog-related example, suppose that the company is best known for their lavish line of slippers. It's probably a good idea to place these products in front of the customer at the earliest opportunity, doing so whenever www.example.com/catalog/list is accessed. You can use variable defaults to set the category and type parameters in the case they don't exist:
Notice how in the Zend_Controller_Router_Route_Static constructor's second parameter we're defining the parameter keys and their default values. You'll subsequently be able to access these parameters using the category and type variable names as was done earlier in this tutorial.
Creating Even Prettier Routes
While the catalog URL used thus far is well-organized, do we really need the category and type keywords? After all, the following URL would be much more succinct without confusing the customer:
To remove the keys, we'll simply omit them when defining the URL! Instead, we'll define the location of the parameters, telling the Zend Framework that they are intended to be parameter placeholders rather than a controller or action name by prefixing the placeholders with a colon, as demonstrated here:
Despite lacking the usual key/value pattern in the URL, the Zend Framework will match the value found in the URL with the keyword defined in the associated position within the custom route. This means you can continue accessing these parameters as you have previously using the $this->_getParam() method:
For that matter, is list even necessary? Granted it's likely preferable to encapsulate the action within an appropriately named action such as list, but that doesn't mean it needs to be named in the URL. To accomplish this effect, while continuing to use the list action as the response mechanism, construct the custom route like this:
Defining this route will allow users to access the catalog via the following URL:
http://www.example.com/catalog/
Conclusion
The Zend Framework's custom routing mechanism is pretty powerful, capable of satisfying even the most esoteric routing needs. I strongly suggest carefully perusing documentation to learn more about all of the possibilities.
