Knowledge Base Overview

Looking through forums I sense that many people have a problem to understand the concept behind Controllers and Action in something like the Zend Framework.

Before I dive into this you should know that this is not an invention or thing with the Zend Framework but a common concept associated to the MVC pattern. The  more you know and understand about this MVC pattern the better you will understand Controllers and Actions in Zend Framework.

I'll have a very, very brief introduction into MVC here and I highly recommend that you learn everything there is to know about MVC.

MVC pattern

The MVC stands for Model View Controller. As you can see we already have our controller here in this pattern definition. Lets break down the MVC real quick before we talk about the controller. To understand Controllers and Actions it is vital to understand the MVC pattern.

The main idea is to break down a request in a web application into certain pieces and deal with them individually. Therefore the three parts in MVC are different areas and they all have different responsibilities in a web request. Lets have a look at them.

Model

The model is usually responsible for anything data related. Whenever you need work with data (and be free and open minded to think what data means) have to think model. What this exactly means or how models look like doesn't matter right now but really anything that is related to managing data should be dealt with in a model class.

View

The view is somewhat self explaining. Whatever it takes to print/echo data back to the user is done in the view part. The Model just mentioned should deliver all the necessary data in a pretty much raw form and it must the responsability of the view to format the data for the requested and intended purpose.

Here's a very quick example for this. Your model could deliver one single piece of data but you could have one view that delivers the data in HTML, another view the same data in XML and maybe a third one that returns it as JSON.

As you can see you can have a regular HTML website with data but also a API returning XML or JSON and for the data part you have to write code only once. The view part in this pattern does the formating of this data.

Controller

Finally the controller will piece these two parts together. The Controller is the part interpreting the request by the user (actually the user agent, aka browser) calling the Model for the data and then passing the data to the approriate view for rendering.

The controller also takes on the responsability of returning the final construct and sets the appropriate header information, like document format, language, caching information and what not.

Controller taking Action

Now that we have a very basic understanding of MVC we can look at the Controller and what Actions are doing in Zend Framework.

In ZF we have this thing called routing. Looking at routing we have some sort of a guideline as to how many Controllers and also Actions we will have in our Zend Framework web application. Although we have to keep in mind that we can do quite a few things to change this in one way (getting less) or another (have even more).

The basic and general rule in ZF for routing is to have a link path matching up with controllers and actions. There are also modules but for this topic and a basic setup you can see that the first part matches a controller and the second an action.

www.yourdomain.com/controller/action

In this basic setup routing will dispatch to the corresponding controller by the same name and within it to the named action. When we follow this basic rule we will end up with a number of controllers that matches our number of paths we like to have in our website. Without an action name in the path we have a default action which is usually name index, i.e. an indexAction() method. The same goes for the Controller; without a controller name in the path we have a default controller usually named index, i.e. a IndexController class and with its indexAction() method.

Now you are pretty much free to structure the paths and with it the contollers. You can basically create a root path for every piece of functionality of you website and end up with as many controller (with one or more actions) but also combine everything within one base path and hence one controller but as many actions as you have nodes in that path.

Little Example

To illustrate all this here's a little example how this may look like on a website.

As we have seen from MVC above Controllers and their actions interpret requests and should only delegate to models and views. Especially models may require a lot of methods to perform tasks. It may be beneficial to keep these methods in their own classes. How you structure this methods and classes is up to you. The Zend way is to keep them in your own application library, e.g. sending emails should be held and performed by a separate class in your own application library (next to and maybe extending Zend classes).

If you have a contact page you could have a /contact link with a ContactController. The indexAction will delegate everything to present the form page. The form could have a /contact/submit link for the submit button and a corresponding submitAction will hook up your email library class and send out the email. The submitAction finally may call something like _redirect('/submit/thankyou') or even /submit/error. As you may guess by now there will be a thankyouAction responsible for presenting a Thank you page or a errorAction to let the user know there was an error.