A Zend Framework tutorial, part three

by Naneau

When I started writing this tutorial I mentioned that I assumed you had the Zend Framework running on your server. I may have falsely assumed that you had a working bootstrap file for it as well. Writing a simple bootstrap file isn’t that difficult, but there are many things you can add to it, some of which may come in handy later on.

What the bootstrap file does is take a look at the request the web-server got from a browser, retrieve some information from it and dispatch that to a controller. While you don’t have to use the standard Zend_Controller_Front for doing just that, it is probably the best way to go, unless you really have to do something special. By default the url structure for a request will look something like:

1
baseurl/controller/action

Baseurl is the root of your application (like http://yourdomain.com/, or http://localhost/zendframework/), and controller and action match controller classes and methods you write. If you follow this standard structure, you get quite descriptive urls for your actions. For our sample web-log application you could see something like:

1
baseurl/post/create

This is pretty descriptive. But when you want to read, update or delete a post, you have to make clear what post you will be working on in the request. You will have to pass some kind of parameter along in the url, to find that post. This could be just an integer id corresponding with a primary key in the database table for your posts. You may want to do something fancy like using a post’s author and title, just to make things more clear for your end users. The standard front controller will look for url parameters in key/value form. You’d end up with an url like:

1
baseurl/post/edit/id/123

Which, although it is descriptive, really should be written like:

1
baseurl/post/edit/123

You can get this behavior by telling the front controller where in the url you expect a certain parameter to be, so you don’t have to pass it’s key with it. You need Zend_Controller_Router_Rewrite for that. You can add dynamic routes to it in the bootstrap file.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$router = new Zend_Controller_Router_Rewrite();
//rewrite router

$router->addRoute(
    'post',
    new Zend_Controller_Router_Route('post/edit/:id', array('controller' => 'post', 'action' => 'update'))
);
//a single dynamic route

$controller = Zend_Controller_Front::getInstance();
//the frontcontroller

$controller->setRouter($router);
//add the rewrite router

If you want to add a lot of dynamic routes, you should really take a look at the addConfig method of the rewrite router. It allows you to create a config file containing the routes outside of the bootstrap file, and use that to specify your url structure. You can find more about it in the manual.

It’s a good idea to design your url structure somewhere early in the process. You may be able to mix it with your requirements list. Because urls are the gateway to your application, you should see are more or less one to one mapping with your requirements.

In part two I showed you a sample method for getting a post using a request parameter. The most important part of it is:

1
$id = (int) $this->getRequest()->getParam('id');

This gets the ‘id’ parameter out of the request, and casts it to an integer. In your controllers you can get the request used to get into that controller with getRequest(), and you can ask this object for specific parameters. In this case, the ‘id’ parameter corresponds with the rewrite route described above, it will be available to the update method of the post controller.

For each request a user makes there should be a matching response. This is the nature of an http web-server. In the controller you can access the response object with getResponse().

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public function readAction() {
    if ($post = $this->getPost()) {
        //private method getPost is described in part two of this tutorial

        $this->getResponse()->setBody('
        <html>
        <head>
        <title>
        ' . $post->title . '
        </title>
        </head>
        <body>
        <h1>' . $post->title . '</h1>
        ' . $post->contents . '
        </body>
        </html>
        ');
    }
}
//bad practice, you need a view for this

You can use the response object to send output back from your controller. You should not use echo, print or anything else that outputs directly in your controllers, but use the the response object instead. In the fourth part of this tutorial we will have a look at views, which is where html comes into play and the “real” response is created and beautified. For your end users, that will be the part that matters, because it is what they will experience.