Zend Controller & Zend View

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.

This article contains information on how to improve your application stability by controlling how the changes affect the Model-View-Controller Zend Framework application. As a result, you will be able to deliver better software to your customers and reduce the time needed for testing of the software.

A few days ago I noted a quick but very usefull tip on how to handle the situation when Front Controller is unable to dispatch the request, i.e. how to display 404 error page instead of Zend_Controller_Dispatcher_Exception with message "Invalid controller specified". And it looks like the common solution for this is to create a front controller plugin. The plugin detects whether the request is dispatchable and changes module/controller/action to appropriate action that will handle the request.