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 typeZend_View_Abstract
. We then set the separator used by theHeadTitle
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 byZend_Paginator
(I plan on further explainingZend_Paginator
in another blog post)._initNavigation()
sets up our navigation structure usingZend_Navigation
(I plan on further explainingZend_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.
3 Comments
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
marsbomber,
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.
Regards,
Rob…
(http://akrabat.com)
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.
2 Trackbacks
[…] my previous post in this series we looked at how Zend Framework applications can be bootstrapped. We saw the […]
[…] http://bradley-holt.com/2010/01/bootstrapping-zend-framework-applications/ […]