Zend Framework – Modules & Layouts
As a UI developer it is important to always be expanding your skillsets. I recently began learning the ins and outs of Zend Framework.
Okay, I’m not the first to say this and I wont be the last, but Zend Framework’s documentation is not just terrible, but abysmally terrible, especially for newbies. The docs are disorganized, often times inaccurate for the current build version, and exhibit a serious lack of useful snippet examples. Zend could really learn a few lessons from the folks at CodeIgniter on how to write decent documentation. PHPDocs are not cutting it guys. Okay, enough of my ranting.
ZendTiger
I wanted to put together a pre-configured setup of Zend Framework that would give me some basic enterprise level administration of users, organizations, permissions and other baseline security features for some of my various projects. I’m calling it ZendTiger.
ZendTiger is a working configuration of Zend Framework 1.11.4 that uses fully autonomous modules and module-specific layouts while keeping the framework’s own internal default routing. The goal was to have self-configuring modules that just drop-in without having to configure any .ini files except what might be within the module itself. I also want to be able to add custom themes or “skins” to the application based on some variable within the layout which can be set automatically within the application itself. The final application also needs to be localized.
Getting Started
One of the first things you learn as a ZF newbie is that Zend does not work out of the box with modules and layouts. It just doesn’t self configure very well. Even with Zend Tool. You will spend not hours, but DAYS, trying to figure out how to get ZF to render pages using its default MVC while also using modules and layouts.
Fortunately, I have done some of the legwork here for you. After days of searching and learning and running into dead ends, I have finally pieced together a clean, working setup of ZF with modules and layouts humming along very nicely without all of the cruft of numerous plugins.
Modules
ZF deals with modules fairly well at this point but modules still have a way to go before they are seamlessly integrated within the framework. Some other ZF engineers have described modules as “second class citizens” of the framework and I am inclined to agree with this notion.
For instance, the Zend Tool CLI does NOT automatically setup modules properly for you. I had to fiddle with the application.ini and module bootstraps for some time before finally getting modules setup and working properly.
The goal of modules is (or should be) to allow for the dropping in of complete and isolated groups of functionality without affecting any other part of the application. This does not mean that modules cannot be dependent (use the functionality of) other modules, it just means that they need to be “drop-in-able” and you should not need to touch anything in the application configuration to make them work. Plug-and-play is the goal.
Also note that module bootstrapping can create a problem for some who are not aware of how modules work in ZF. ALL bootstrapping files are processed from all modules during the bootstrapping process, not just the active module’s. This is done on purpose because of possible module interdependencies, or one module needing the functionality of another module. If you build your bootstrapping without some kind of logic within your bootstrap files, you can easily have your modules overwriting the bootstrapping of other parts of your application. Keep this in mind when setting up your bootstrap files.
Layouts
Modules open the door to the desire to have different themes or skins for different modules of the application. Module-specific layouts is how this is achieved. However, once again, ZF doesn’t provide this configuration for your out of the box. Enabling Layouts using Zend Tool and then creating a module will not automatically add a /layouts folder to your newly created module. You have to do this by hand.
Once you initialize Zend Layout, there really isn’t an inherent way nor obvious way to configure ZF to use module-specific layouts. Many of the examples I looked at online of how to configure ZF to use layouts were either very complex for older versions of ZF, or the solutions just didn’t seem like the people writing them knew what they were doing in working WITH the framework. My coding philosophy is never work against the framework, work with the framework’s inherent ability whenever possible.
The simpler the code the better.
Most people want layouts to be set automatically based on the module being called. If a module has its own layout, we need to use that; if a module has no layout, use the default. This kind of logic for setting the layout automatically is best placed in a plugin at a point when the module name is known and the Zend Layout class has been instantiated. ZendTiger’s Layout plugin does this just after the routerShutdown event. This very early setting leaves open option of re-setting /overriding the layout within the controller if necessary, like with error message pages.
…
Conclusion
I’ve not posted a bunch of code snippets here at this point, just download the ZendTiger files and you’ll be up and running. ZendTiger expects your ZF library files to already be in your PHP path. If ZendTiger cannot find your ZF files, setup your environment so that PHP knows where your ZF library files live.
I’ll add more as I continue developing … I hope ZendTiger saves you a lot of time. Cheers!
Downloads
The following file is the latest working version of ZendTiger.
Credits
I could not have gotten very far on this project without the help of the following people and their blogs:
Jeroen Keppens of Amazium
Leonard Dronkers of Sreknord
If WebTigers has helped you out, feel free to link to us!
____________________________
K. Beau Beauchamp is a professional UI developer with over 15 year’s experience in graphic design, marketing communications and object-oriented UI programming. Beau can be contacted via email here.