Sunday, January 31, 2010

Bootstrapping Zend Framework Applications

See Bootstrapping Zend Framework Applications at its new home on

In my previous post I talked about how the Front Controller pattern is implemented in Zend Framework. We saw how every application request can go through the public/index.php script. Everything that your application does is then eventually called from either the bootstrap() or run() method in Zend_Application.

One of the constructor arguments passed to Zend_Application specified the configuration file to use. In the case of the demo blogging application, Postr, you'll see that the configuration file used is application/configs/application.ini. If you look at this configuration file you'll see that there are four sections: production, staging, testing, and development. The staging, testing, and development sections all inherit from production meaning that they will inherit all of its settings, unless overridden (as is the case, for example, with the phpSettings.display_errors setting in testing and development).

The other constructor argument passed to Zend_Application specified the application's environment. For those paying close attention, the environment was actually the first argument and the configuration file was the second argument passed to the constructor of Zend_Application. By default, the demo application is set to run in development mode. This means that the development section from application/configs/application.ini will be used. Remember, development inherits from production so any settings not explicitly overridden from production would be inherited and used.

There's quite a bit that can be setup in the configuration file. However, some things may be easier to (or only possible to) setup programmatically. This is where application/Bootstrap.php comes in. In your Bootstrap class you can write initializers for various parts of your application. These methods should be protected and their names should begin with _init. Let's look at the initializers I've written in the demo application:

  • _initViewHeadTitle() first makes sure that the "view" resource has been bootstrapped and then gets this resource, which we happen to know is an object of type Zend_View_Abstract. We then set the separator used by the HeadTitle view helper to " :: ". This means that each head title appended or prependend will be separated by this string. Next, a title of "Postr" is prepended so that this title will be used on every page.
  • _initPagination() simply sets the partial view script to be used by Zend_Paginator (I plan on further explaining Zend_Paginator in another blog post).
  • _initNavigation() sets up our navigation structure using Zend_Navigation (I plan on further explaining Zend_Navigation in another blog post as well).

In my next post in this series I plan on taking a look at the Model-View-Controller pattern in Zend Framework.


marsbomber said...

Bradley, may I ask the difference between the return types of these _initBlah functions? ie, _initViewHeadTitle() returns nothing, void in another term. compare to _initNavigation(), which returns Zend_Application_Resource_Navigation. thanks

akrabat said...


Anything you return from an _initXyz() method is available to the application via getResource. Therefore, you return data that you want the rest of the application to have access to.

In this case, _initViewHeadTitle() doesnt need to share anything, so returns nothing. _initNavigation() shares a Navigation object that the application will want to use elsewhere.



marsbomber said...

hi rob, thanks very much. btw, it's your zend framework in action book that got me going with zf. just want to say thank you for that too.