Zend_Controller 2.0 RoadMap

Zend_Controller_Action Changes

Some proposed changes:

Re-instate noRouteAction()

Reinstate the noRouteAction() as an empty method (throwing an exception) in Zend_Controller_Action. __call() would then detect method calls ending in 'Action' and call this method.

By itself, this does not represent a BC break; __call() would simply proxy to this method, which would throw the same exception as currently thrown in __call(). Overriding the method would be similar to overriding __call() in current versions.

Use overloading to access action helpers

__call() would be modified to determine if a method call is a helper name, and, if so, call its direct() method. __get() would be added, and would do similarly, only it would return the helper directly. This would make calls to helpers much simpler, and make them mimic the behavior of view helpers more directly - leading to better consistency in the framework in general and MVC layer in particular.

As an example,

would simply become:

As an example showing property access:

could become:

This would be a slight BC break - but only for developers overriding __call(), and then the BC issues would be limited in scope. $_helper would continue to be registered, so all previous calls to helpers would work. When overriding __call(), you simply wouldn't be able to call helpers as controller methods, since the logic to proxy to the helper broker would not be present.

Revise Zend_Controller_Plugin_Abstract

There's no reason for the plugin methods to accept a request object; the abstract already has a getRequest() method. Additionally, an interface should also be created.

Integrate the Page Controller pattern

We should explore the possibility of allowing for the Page Controller pattern to be implemented in a way that would support its use with Action Controllers as well as allow it to integrate with the majority of action helpers that currently exist.

This solution would be a viable option for those situations where the cost of having a Front Controller based MVC solution is too high.

A Page Controller solution would offer extreme high availability, more throughput, and a simpler architecture. This would be achieved through having a very lightweight router and dispatcher solution and would leverage the server (ie: ability to route to actual pages on a file system) to handle part of the routing load.

Zend_Controller_Front improvements

Provide a full debugging mode

Actually, the only thing we can do to debug is to throwExceptions(true). We should add some more methods, those which could use new proposals about Zend_Debug, Zend_Log, Zend_Exception ...
There is a proposal for making a plugin dedicated to debug, and an integration of FirePHP, see here.
Too, it could trigger $viewObject->setStictVars(true) or other things like that that could really help debugging, but without being too heavy (some other frameworks add so much debug infos that the response become unreadable, and takes a while to be dispatched)

Make the use of the view simpler

If I want my view in the bootstrap, I have to use something like that :

Wow. I could create it, and pass it back to VR, but it's the same headache...

Why not have a Zend_Controller_Front::setView() method that would do all that work for us (taking care of the case where VR has been disabled) ? Zend_Controller_Front("FC") is used as a "master chief" of all the MVC objects, we actually can ask it for lots of objects (Plugins, Request, Response ...). Shouldn't there be a bridge between FC and the View object, even if FC just proxies it to VR ?

Paka Yoke filtering

In an action, _getParam() doesn't do anything that is usefull actually, thinking about direct acces to $_GET, POST ... (am I wrong ?)
Why not create a method aka Zend_Controller_Front::setPakaYokeFilter(Zend_Filter_Input $filter), or something like that. The method should also (as Paka Yoke means), unset all get post cookie original arrays.