With the release of Zend Framework 1.5, the Zend_View component received a long overdue boost in its functionality. It is now no longer a simple template engine, but a powerhouse of features intent on making the dynamic generation of a View as simple and as flexible as possible. This update introduced a few new concepts along with existing ones which form the backbone of the changes. The main ones are as follows:
1. View Helpers
2. Layouts
3. Partials
4. Placeholders
We’ve already met Layouts as represented independently from Zend_View by Zend_Layout. The purpose of Layouts is to setup the HTML which is common to all Views of the current Module, i.e. headers, footers, sidebars, etc. Specific templates can then be rendered, have their output strategically inserted in the Layout body, and the final result send to the client browser. I haven’t gone into huge detail on its use other than to setup global Layouts which is its simplest and most common use. But some digging will reveal more of its functionality, for example, chaining action calls to aggregate output.
View Helpers we’ve also touched on briefly. They are classes which attach new callable methods to Zend_View and were introduced to allow presentation logic to be segregated for reuse in a separate class. For example, Zend_Form uses View Helpers to generate a form by calling on individual helpers such as Zend_View_Helper_FormTextarea, etc. There are also View Helpers for tasks as specific as URL generation, form elements and HTML lists. You can even write your own, and indeed it’s encouraged to keep your templates clear of duplicated code. The next two items on our list are introduced separately, but they are themselves View Helpers with more far reaching uses.
Partials were designed to offer the same benefit of reusable presentation logic that View Helpers offer, only this time for template code itself. For example, our index page involves displaying a list of blog entries. Each entry’s HTML is essentially identical except for the content injected into it. So it would be a good idea for us to create a template for one single entry, add this template as a reusable Partial, and simply render one in sequence for each entry we want to display. The same idea is adaptable for lists, menus, and more.
Then, instead of lots of templates with Entry markup, there is only one! Other templates can simply include it, render it from iterated data, etc. But the biggest selling point is variable scope - a Partial is completely blind to any data other than the data you deliberately give it. This trumps using includes and render() since it significantly reduces surrounding code and removes any chance of variable name clashing in a large application. In fact there’s a subclass called the PartialLoop helper which makes looped rendering of Partials incredibly easy.
Placeholders were conceived for a slightly different reason. The problem with having Layouts, templates, Partials, and View Helpers is that one View can be built up using a lot of different parts, which are unable to communicate with each other without introducing some custom wiring. Placeholders ensure that such wiring is standardised - if you have an entry template which outputs content and needs to change the title of the page, it can use a Placeholder to set the title value, and then you can add a sprinkling of code in your Layout to read that value and inject it into the Layout’s
We’ll see these facets of Zend_View in action as we continue.
