27 March 2008:
With the inclusion of Zend_View Enhanced as first documented, discussed and publicised in this blog series, in the Zend Framework as of 1.5.0 I’d like to thank everyone involved in the process. A few of you pioneered it’s implementation and provided immense feedback which tailored the proposal to some specific needs, others kept bringing it up on the mailing lists and to the attention of the Zend reviewers, and others still spent a lot of time converging ideas towards a unified proposal. It just goes to show that the community really does have the power to influence the big picture and get stuff done!

The rest of this series can be accessed as follows:
http://blog.astrumfutura.com/archives/283-Complex-Views-with-the-Zend-Framework-Part-3-Composite-View-Pattern.html
http://blog.astrumfutura.com/archives/285-Complex-Views-with-the-Zend-Framework-Part-4-The-View-Factory.html
http://blog.astrumfutura.com/archives/288-Complex-Views-with-the-Zend-Framework-Part-5-The-Two-Step-View-Pattern.html
http://blog.astrumfutura.com/archives/291-Complex-Views-with-the-Zend-Framework-Part-6-Setting-The-Terminology.html

Recently I’ve been involved in a long discussion about the Zend Framework on the PHP Developers’ Network forum. Our approach was to pick a simple application (we decided to borrow the Java BluePrints Pet Shop for J2EE) and starting from a basic “Hello World!” example for the Zend Framework work towards a fully functional example. Of course, one of our goals wasn’t just to “do it”, we wanted to explore the framework in greater detail, and identify how best to use, misuse, subclass, and where it was logical to even replace components should they prove deficient for our needs.

After wrangling about configuration, the advantage/disadvantage of build tools (I love Phing and cannot survive without it!), the location of the bootstrap file, and a few other odds and ends we finally put up the “Hello World!” example in subversion. Many thanks to Chris Corbyn of Swiftmailer fame for contributing the repository!

http://w3style.co.uk/devnet-projects/pet-store/trunk/

We then decided to look at how the Zend Framework implements Views. In essence, the framework isn’t as developed in that respect as its peers. A simple page is easily built using a Zend_View instance, a PHP/HTML template for a list of entries, and a few view helpers and filters. After that however, a complex page becomes progressively more difficult. This is complicated in part by the growing practice of instantiating Views using a helper function on the Controller – unfortunately this is unusable since it introduces coupling making re-use more difficult in other applications where the View has been subclassed.

Back on track, the main problem of a complex View, is that the current Controller is only aware of a subset of its own required Model (data) and the current View. So how do do you get the View to include extra sections – for example, details from Technorati for your blog – which are common to ALL pages?

The Zend Framework currently suggests using a Controller’s _forward() method – basically if your current View needs data from Technorati, then forward from the current Controller to a “TechnoratiController” to fetch it and assign it to the View, and then _forward() back. This works for simple things – but what if there are three, or even more sections? What if some sections, have additional embedded sections? How in heaven’s name are you supposed to track all those _forward()’s?

While pondering the problem, we all agreed using the Controller _forward() was not a good idea – it’s prohibitively complex, forces Controllers to become aware of other (possibly unrelated) controllers, and in general doesn’t promote reuse. I haven’t measured the performance impact of such a tactic but it can’t be good. We also determined the Zend Framework’s view helpers were of limited use being simple classes designed to offer a single public method to templates.

Finally we decided to visit two design patterns to help name the problem and offer a possible solution: Composite View and View Helper. So far we’ve just implemented a very basic Composite View (KISS) to further the brainstorming. But it shows a lot of promise in offering a simple, effective solution to building complex web pages with the Zend Framework – granted it breaks the normal practice, and takes subclassing to introduce, but it’s a reusable solution.

I’ll visit Composite View in more depth soon – for the moment here’s the J2EE BluePrints page for the design pattern: Composite View. If anyone knows of a really good example in PHP or Ruby, it would be great to hear about it!

On the View Helper bit – the Zend Framework seems to persist a belief that only Controllers should interface with the Model layer (i.e. Database and associated Model classes). This Model-Push strategy can be complemented with an equally valid Model-Pull strategy – where View Helper classes have the ability to directly access and read data from the Model to pass to the requesting View. This completely avoids the fickle tactic of Controller forwarding and the complexity it tends to introduce into an application.

Stay tuned for a deeper look at both these patterns – specifically how they can be brought to bear on the Zend Framework with a little subclassing of Zend_View.