Inside BaseApp, Part 1 - Zend Framework and the Bootstrap

This entry is about the use of Zend Framework and BaseApp, an application layer built on top of the framework libraries.

One of the things I noticed as I was getting started with the Zend Framework libraries was the smell coming from all of the bootstrap files... a lot of setting of variables, adding directories to this or that, creating various objects for random tasks, and a growing urge to do more and more setup in this bootstrap. This is BAD practice for a few reasons, but here are the two big ones for me:

• Maintainability - did we not learn from php4? Non-OOP code just gets worse and worse over time. It gets unorganized, it gets unfocused, and soon the bootstrap, just like the index.php scripts of old, begin to do too much for their role.
• Reuse - which sounds like a better idea: copying the code over and modifying the section that you want to act differently? or extending a class and only writing new code where its applicable? If you found yourself nodding in approval to the first option, buy this book for good insight into why the second option will make your life much easier.

BaseApp minimizes the bootstrap to a very simple form: set the application path, instantiate the main application class, call any special configuration methods of that object, then execute the main method of the application object. In the included example index.php, this is 5 lines of code. The application object, BaseApp_Loader, handles all of the specific setup that you otherwise see in bootstrap files.

So what about BaseApp_Loader? What does it do? Why is it better than a typical bootstrap?

• XML Configuration - Uses Zend_Config_Xml to load an application level configuration file. Now if you want to launch a second copy of a site, for example, you can use the same exact code libraries and point at different configuration file to use different databases, etc. By using an xml configuration and capturing exceptions through the main application setup process, simple errors like typos won't bring your site crashing to 500 Internal Server Error.
• Method Based Configuration - Each type of configuration is split off into its own method within BaseApp_Loader, so if you want to setup logging to do something other than Zend_Log, or configure database usage differently than the default Zend_DB implementation, you can override the individual method in an extension of the BaseApp_Loader class. Each of these methods receives a Zend_Config object rather than referencing the application's config directly, allowing for easy overrides by subclasses while minimizing the impact of the underlying structure.
• Zend_View Choices - Included in the default implementation are Zend_View and BaseApp_View_Smarty (a Smarty based view). BaseApp allows you to decide what view you want to use in a way that is flexible, and you can add your own if you want (by following BaseApp_View_Smarty as an example, if you need).
• Easy Registration - For modules, views, log control, database control, helpers and more. Utilizing these powerful constructs provided by the Zend Framework libraries is extremely easy using the BaseApp_Loader's methods or overriding them with your own.