ZF-4385: Create Zend_Controller_Action_Interface and make Standard Dispatcher check for it.

Issue Type: Patch Created: 2008-09-26T03:38:44.000+0000 Last Updated: 2009-07-13T14:36:51.000+0000 Status: Resolved Fix version(s): Reporter: Benjamin Eberlei (beberlei) Assignee: Jurrien Stutterheim (norm2782) Tags: - Zend_Controller

Related issues: Attachments: - Controller_Action_Interface.patch


Currently the whole controller dispatcher and controller action components are very thighly coupled, since the Standard Dispatcher checks for an Zend_Controller_Action instance before dispatching. I propose to include a Zend_Controller_Action_Interface with just the constructor and the dispatch method required for any implementation. Make Zend_Controller_Action implement the new interface and the Standard Dispatcher to accept the interface as allowed action controller.

Advantages: * Standard Dispatcher (Dispatcher in general) and Action Controller are now lously coupled. * People can implement their own action controller following their needs. * No BC issues, only added a new interface, old functionality stays 100%. All Unit-Tests still succeed. * Even when MVC will be refactored in the future, this is still just a simple change that may lead only to problems for those who changed from the default Zend_Controller_Action implementation to a user-implemented one and those have probably to refactor anyways.

My use case would be to implement a new controller that handles everything as a SOAP request, you could of course insert any other webservice, so that a controller MyApp_Controller_Action_Soap will completly handle soap requests and still have all the advantages of a front controller approach. Currently you have to write non-DRY code for this or overwrite the Zend_Controller_Action class and have the problemt that many methods in the abstract class are public and even final, and can't be restricted access to.


Posted by Benjamin Eberlei (beberlei) on 2008-09-26T03:39:47.000+0000

Patch implementing a new Zend_Controller_Action_Interface, having the action controller implement it and changing the Standard Dispatcher to accept the interface as correct action controller implementation.

Posted by Benjamin Eberlei (beberlei) on 2008-09-26T04:31:30.000+0000

ah its probably important to say, the patch has to be applied to library/Zend/Controller directory. :-/ my mistake

Posted by Dolf Schimmel (Freeaqingme) (freak) on 2008-09-30T08:19:40.000+0000

I just voted for this issue. I was actually quite amazed that a basic thing like this has been so thightly coupled for such a long time. I didn't expect to find that in framework that tries to have / has a use-at-will architecture ;)

Posted by Jurrien Stutterheim (norm2782) on 2009-02-21T15:49:19.000+0000

Resolved in revision 14138

Posted by Matthew Weier O'Phinney (matthew) on 2009-02-21T20:27:54.000+0000

Jurrien -- we actually need to back this out as it introduces a BC break.

Posted by Matthew Weier O'Phinney (matthew) on 2009-02-21T20:28:20.000+0000

... and should have noted that it's a good candidate for 2.0...

Posted by Jurrien Stutterheim (norm2782) on 2009-02-21T20:31:53.000+0000

Curious... how does this break BC? Unit tests still pass...

Posted by Matthew Weier O'Phinney (matthew) on 2009-02-22T07:24:55.000+0000

Because it changes the types it looks for. I'll take a closer look, however. Let's discuss on Monday.

Posted by Jurrien Stutterheim (norm2782) on 2009-02-22T12:12:22.000+0000

I'm currently behind a firewall that doesn't allow me to do anything, including committing changes to SVN. Will be able to do that later today. However, if the type check is the main concern, this simple check in Zend_Controller_Dispatcher_Standard would resolve that:

Line 262:

<pre class="highlight">
if (!($controller instanceof Zend_Controller_Action_Interface) ||
    !($controller instanceof Zend_Controller_Action)) {

Posted by Jurrien Stutterheim (norm2782) on 2009-02-23T22:45:28.000+0000

I've applied the patch I proposed in my previous comment in revision 14152. This resolves any BC issues that might have occurred with the first patch.

Posted by Todd Pinkerton (toddp) on 2009-07-13T14:23:55.000+0000

I ran into a problem with this interface as implemented in 1.8.4, in that my test harness defines classes for each controller under test, as described in this article:…

to the point, I am extending a controller and changing the constructor (and its signature) in the derived class. This is not possible with the new Zend_Controller_Action_Interface.

I know supporting this method is not the concern of ZF, but the new interface does break this approach. The larger problem is that it breaks general OOP design principles, in that derived classes should be free to instantiate themselves however they see fit. WIth the new interface, ANY class implementing Zend_Controller_Action_Interface -- INCLUDING any class that extends Zend_Controller_Action -- must have that constructor signature. This just seems wrong. In fact, I found much supporting arguments for all sorts of OO languages when doing a quick google search on this subject:

This is my first ZF comment, so I apologize for not having a lot of the history here. But I hope this causes some second thoughts about placing constructors in the interface, thereby enforcing needless constraints on any derived classes.

Posted by Jurrien Stutterheim (norm2782) on 2009-07-13T14:29:40.000+0000

Could you open a separate issue for that please? :)

Posted by Todd Pinkerton (toddp) on 2009-07-13T14:36:51.000+0000

new ticket created:

Have you found an issue?

See the Overview section for more details.


© 2006-2019 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.