compared with
Current by julien PAULI
on Jul 20, 2008 15:53.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (52)

View Page History
h1. Zend_Controller 2.0 RoadMap
<h1>Zend_Controller 2.0 RoadMap</h1>


h2. Zend_Controller_Action Changes
<h2>Zend_Controller_Action Changes</h2>

Some proposed changes:
<p>Some proposed changes:</p>

h3. Re-instate noRouteAction()
<h3>Re-instate noRouteAction()</h3>

<p>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.</p>

<p>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.</p>

h3. Use overloading to access action helpers
<h3>Use overloading to access action helpers</h3>

\__call() <p>__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.</p>

As an example,
{code:php}
<p>As an example,</p>
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$this->_helper->redirector('index');
{code}
would simply become:
{code:php}
]]></ac:plain-text-body></ac:macro>
<p>would simply become:</p>
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$this->redirector('index');
{code}
As an example showing property access:
{code:php}
]]></ac:plain-text-body></ac:macro>
<p>As an example showing property access:</p>
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$this->_helper->viewRenderer->setNoRender(true);
{code}
could become:
{code:php}
]]></ac:plain-text-body></ac:macro>
<p>could become:</p>
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$this->viewRenderer->setNoRender(true);
{code}
]]></ac:plain-text-body></ac:macro>
<p>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.</p>

h2. Revise Zend_Controller_Plugin_Abstract
<h2>Revise Zend_Controller_Plugin_Abstract</h2>

<p>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.</p>

h2. Integrate the Page Controller pattern
<h2>Integrate the Page Controller pattern</h2>

<p>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.</p>

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

A <p>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.</p>

h2. Zend_Controller_Front improvements
<h2>Zend_Controller_Front improvements</h2>


h3. Provide a full debugging mode
<h3>Provide a full debugging mode</h3>

<p>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|http://framework.zend.com/wiki/display/ZFDEV/Zend_Log], [Zend_Exception|http://framework.zend.com/wiki/display/ZFDEV/Zend_Exception] ... <a href="http://framework.zend.com/wiki/display/ZFDEV/Zend_Log">Zend_Log</a>, <a href="http://framework.zend.com/wiki/display/ZFDEV/Zend_Exception">Zend_Exception</a> ...<br />
There is <a href="http://framework.zend.com/wiki/display/ZFPROP/Zend_Wildfire_FirebugLogWriter+-+Christoph+Dorn">a proposal</a> for making a plugin dedicated to debug, and an integration of FirePHP, <a href="http://www.firephp.org/Wiki/Libraries/ZendFramework">see here</a>.<br />
Too, it could trigger $viewObject->setStictVars(true) $viewObject-&gt;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)</p>

h3. Make the use of the view simpler
<h3>Make the use of the view simpler</h3>

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

{code}
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$vr = Zend_Controller_Action_HelperBroker::geStaticHelper('ViewRenderer'); $vr->init(); $view = $vr->view
{code}
]]></ac:plain-text-body></ac:macro>
<p>Wow. I could create it, and pass it back to VR, but it's the same headache...</p>

<p>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(&quot;FC&quot;) is used as a &quot;master chief&quot; 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 ?</p>

<h4>Paka Yoke filtering</h4>

h4. Paka Yoke filtering

<p>In an action, \_getParam() doesn't do anything that is usefull actually, thinking about direct acces to $_GET, POST ... (am I wrong ?)<br />
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.</p>