Comments on: Zend Framework Module Init Script (Controller Plugin)

By: Daniel Cousineau

Daniel Cousineau — Thu, 29 Jan 2009 01:34:54 +0000

@Amit: Frankly you will need at least a controller directory, however what you can do is have your controller directory hidden away and use the module-specific errorcontroller plugin (http://www.toosweettobesour.com/2008/08/11/quickie-module-specific-error-controllers-in-zend-framework-15/) to select views to display.

By: Amit sharma

Amit sharma — Fri, 23 Jan 2009 09:04:20 +0000

Can we Build a CMS in zend framework where controller directory is not used.
waiting for reply

By: blunt

blunt — Fri, 09 Jan 2009 18:38:47 +0000

Adding the Module loader to the addControllerDirectory would cause it be loaded on all requests, even if that request is not for that module – since the routing class has yet to determine what the requested module is and you’d need to add the controllerDirectory in order to add it to the list of valid modules?

For the router plugin, certainly a good exercise of thought, another might be if that all respective application module controllers extended a base controller, then just doing that in the preDispatch ‘could’ suffice? Reason for saying that is that a router plugin would not of been the first association of where ‘to look’, maybe.

By: Daniel Cousineau

Daniel Cousineau — Wed, 07 Jan 2009 20:40:10 +0000

Ah, I see what you’re saying.

I could easily modify my plugin to do a routeStartup(), I think you’re still able to inject a route… However that would obviously have to dig through every module and include a file (in this case it may be best to move towards a file that contains a module class).

My code only needed to run only when in the specific module.

By: Ralph Schindler

Ralph Schindler — Wed, 07 Jan 2009 20:25:06 +0000

Well, let me further explain the ideas behind putting it inside the addControllerDirectory(). In my mind there is a single driving factor: reusable modules. In order for them to be drop in and go, some modules might need to have a place to bootstrap themselves, and this typically means prior to any “dispatching”. This then allows modules (that are bootstrappable), to be able to inject routes (something that needs to happen before routeStartup), and to effectively “bootstrap” all their needs (even throw bootstrap exceptions).

To do this, the module would need to be hooked in during addControllerDirectory time. The reasons for putting it inside the dispatcher is so that there is no prerequisite for any given reusable module to have the moduleInit plugin enabled.. it can simple expect to work in most, if not all, ZF FrontController environments.

Consider this the way that the FrontController (during bootstrap), delegating module bootstrap back to the Module, instead of forcing developers to add code to their bootstrap to make it run.

-ralph

By: Daniel Cousineau

Daniel Cousineau — Wed, 07 Jan 2009 19:37:29 +0000

Personally I think we’re best off with this functionality as a Controller Plugin that is included/enabled by default (essentially mimicking the ViewRenderer). (A) we’ll be consistent with the standard built by the ViewRenderer, (B) keeps ZF modular (easy to extend), and (C) easy to disable as well as maintain.

However your approach of placing it as a custom dispatcher works well too.

By: Ralph Schindler

Ralph Schindler — Wed, 07 Jan 2009 17:03:56 +0000

I actually had done the same thing a month or two back, only handled inside the dispatcher. This “feature” is something we are considering in 1.8 along with the Zend_Application initiative.

You can see my prototype here:

http://svn.ralphschindler.com/repo/Scratch/ZFApp+ModuleInitSupport/library/ZendL/Controller/Dispatcher/Standard.php