Zend Controller & Zend View

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.

IÂ’m using the Zend Framework at the moment and came across a problem with creating custom helpers for the Zend_View class. All is fine if you place your helpers either within the zend frameworkÂ’s own helpers folder (not a good idea) or within a directory in your site structure. The problem arises if you place the helpers in a folder in the PHP include path and donÂ’t know the full path to the folder.

Early versions of the Zend Framework had a noRoute action that was called when the correct action couldnÂ’t be found. This was a way to deal with some page not found errors. At some point it was dropped - I donÂ’t know when or why because I only started using the Zend Framework recently. ItÂ’s still possible to handle non-existent actions using the __call() method of the controller class. But thereÂ’s no obvious way to deal with all page not found errors in one place, including instances where the controller doesnÂ’t exist.

Web site developers are familiar with a concept that a site consists of pages but Zend Framework proposes Controller/Action idea. Undoubtedly, Controller/Action is cool but how is it relevant to real world tasks? In other words, how is Controller/Action connected to the standard form flow?

I was wondering about how to extend a singleton class such that you could retrieve the new class when retrieving the singleton later. In particular, Zend_Controller_Front is a singleton, but what if I want to extend it later? A number of plugins in the Zend Framework, particularly view helpers and routing functionality, make use of the singleton; would I need to alter all of these later so I could make use of the new subclass ?