Zend Controller & Zend View

In the previous two parts of this series of blog posts, I've been looking at the task of implementing complex views with the Zend Framework. Part 1 looked at what complex views are, what support for complex views the Zend Framework offers out of the box, and a reference to two design patterns useful in adding further support: View Helper and Composite View. In Part 2, I tackled the View Helper design pattern.

It's been a while since I continued this series. Unfortunately real life workloads are unforgiving of the best of intentions ;-). Part 5 of our series takes a small time-out from approaching a Composite View solution to reusable Views to take a peek at a simpler approach useful for simpler types of web applications. As we've discussed previously Composite Views allow the nesting of reusable View elements, effectively building a View based on a hierarchy of Views. But often there are simpler solutions to simpler problems. One such solution is the Two-Step View pattern, sometimes called Layouts if implemented in a specific way (as we do below!).

A tutorial about using Zend_Translate to write multilingual applications

Half the trouble in conceiving of a extended View system is agreeing on terminology. Everyone has their own idea of the basic concepts, but without names we're left with vague descriptions. Here I'll throw out some terms, some borrowed, others mangled slightly, the rest fairly obvious. These terms all describe specific rendering processes. Methods of capturing presentation logic in neat parcels which carry specific consequences, follow object oriented practices, and provide (we dare hope) commonly sought functionality.

Because I noticed some people find it difficult to understand the routing process the Zend Framework uses by default, I decided to write a little explanation. It’s really easy once you get the hang of it, even though it may seem complicated at first.

Part two of my ongoing look at the View layer of the Zend Framework turns its attention to the topic of View Helpers. The Zend Framework manual provides a fairly narrow definition of its helpers which indicates they enable complex tasks, like generating form elements, to be extracted out of views into dedicated helpers. Here I'll try to explain in greater depth the View Helper pattern which is another of those patterns in the J2EE catalog, and which adds to the range of tasks View Helpers are capable of performing.

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.

Continuing from my post last week of notes on the Zend Framework, I’d like to provide some pointers on using helpers with views in a much more automated way. Just as views can be automated—that is, you don’t have to instantiate a Zend_View object; the controller does it all for you when you call $this->render() from any controller action—you do not have to explicitly tell Zend_View where your helpers reside, as the manual suggests. Instead, place your helpers in a special “helpers” folder where the Zend_Controller_Action’s initView() can find them.

IÂ’ve been working a lot lately with the Zend Framework for a project at work, and in a recent upgrade from 0.8.0 Preview to 0.9.1 Beta, I made a few discoveries that IÂ’d like to share, especially since the manual for the Zend Framework is sorely out of date, and many of the examples are either deprecated or no longer work.

After getting a little impatient looking at PHP code from however many projects and seeing the typical approach of making input filtering, sql and output escaping the responsibility of the human error-prone developer, I'm now making it standard practice on any of the projects I run to dump this sorry mess. And it is usually a mess. The fact is you cannot trust a developer to manually secure source code - it's like God relaying the Ten Commandments to Moses. No matter how many burning bushes, prophets, unnatural disasters, signs and miracles you use to emphasis those ten simple rules, you can still wager there will be a bunch of folk breaking them (including myself!) left, right and centre. It's human nature to err. It's my nature to make the verb "err" redundant.