Module Bootstrap

[Simon Walter]

Is there a way to completely disable a module? Would generating 404 from
the module's bootstrap be sufficient? How about the autoloader? Is there
a way to stop that?

I'm making a module registry system with dependency. So a module should
not be accessible at all, unless certain requirements are met.


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[markizano]

Hi Simon,

> Is there a way to completely disable a module? Would generating 404 from the module's bootstrap be
> sufficient? How about the autoloader? Is there a way to stop that?

You can remove the module from your resources.modules listing so the controllers
for that module are not registered.
The front controller should throw a 404 for those modules/controllers that are
not registered:

https://github.com/markizano/markizano/blob/master/application/configs/application.ini#L121

Hope this helps,
-Kizano
//-----
Information Security
eMail: [hidden email]
http://www.markizano.net/

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Simon Walter]

On 04/05/2011 09:21, Mark Harris wrote:

> Hi Simon,
>
>> Is there a way to completely disable a module? Would generating 404
>> from the module's bootstrap be
>> sufficient? How about the autoloader? Is there a way to stop that?
>
> You can remove the module from your resources.modules listing so the
> controllers for that module are not registered.
> The front controller should throw a 404 for those modules/controllers
> that are not registered:
>
> https://github.com/markizano/markizano/blob/master/application/configs/application.ini#L121 
>
>

That's a "manual" way to do it. I need to be able to do this via PHP. I
have this in my application.ini:

resources.modules = ""

Which effectively loads all the existing modules. I need to be able to
do some tests and then if the requirements are not met, disable the
module so that it cannot be used.

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[markizano]

Hi Simon,

> I need to be able to do some tests and then if the requirements are not met, disable the module so
> that it cannot be used.

I think, then a good solution would be:

Zend_Controller_Front::getInstance()->removeControllerDirectory($module);

That would effectively remove all controllers associated with that module,
thereby allowing you to disable the module :)

Hope this helps,
-Kizano
//-----
Information Security
eMail: [hidden email]
http://www.markizano.net/

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Simon Walter]

On 04/05/2011 10:53, Mark Harris wrote:

> Hi Simon,
>
>> I need to be able to do some tests and then if the requirements are
>> not met, disable the module so
>> that it cannot be used.
>
> I think, then a good solution would be:
>
> Zend_Controller_Front::getInstance()->removeControllerDirectory($module);
>
> That would effectively remove all controllers associated with that
> module, thereby allowing you to disable the module :)

That sounds good. Thanks Mark!

 From looking at some of the module related methods of
Zend_Controller_Front, I'm wondering if the dispatcher(?) scans *all*
the module directories and does some bootstraping or loading of all
modules regardless of if they are being accessed. Or if it is *only* the
module specified in the route/URL?

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[omerida]

On Tue, May 3, 2011 at 10:20 PM, Simon Walter <[hidden email]> wrote:

> From looking at some of the module related methods of
> Zend_Controller_Front, I'm wondering if the dispatcher(?) scans *all* the
> module directories and does some bootstraping or loading of all modules
> regardless of if they are being accessed. Or if it is *only* the module
> specified in the route/URL?
>
>
>
Module bootstraps are run on every request, I found Matthew's post very
helpful:

http://weierophinney.net/matthew/archives/234-Module-Bootstraps-in-Zend-Framework-Dos-and-Donts.html


--
Oscar Merida
* http://OscarM.org - random thoughts on my blog
* http://SoccerBlogs.net - your daily soccer feed
* http://FutBoliviano.com - bolivian soccer, futbol de altura

[Simon Walter]

On 04/05/2011 12:29, Oscar Merida wrote:

> On Tue, May 3, 2011 at 10:20 PM, Simon Walter<[hidden email]>  wrote:
>>  From looking at some of the module related methods of
>> Zend_Controller_Front, I'm wondering if the dispatcher(?) scans *all* the
>> module directories and does some bootstraping or loading of all modules
>> regardless of if they are being accessed. Or if it is *only* the module
>> specified in the route/URL?
>>
>>
> Module bootstraps are run on every request, I found Matthew's post very
> helpful:
>
> http://weierophinney.net/matthew/archives/234-Module-Bootstraps-in-Zend-Framework-Dos-and-Donts.html
>

This is very interesting and helpful. I've looked at some of the others'
code and comments. There's no use in waiting for ZF2. Hopefully my code
will be neat enough to change easily over to any new and powerful ZF2
module related techniques once that's ready.


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Simon Walter]

I'm thinking that extending or using my own class for the module loading
would be a better idea than calling
Zend_Controller_Front::getInstance()->removeControllerDirectory($module)
for every module that doesn't meet certain criteria.

I started snooping around the API docs, and honestly, I have no idea
what I'm looking for. How can I replace the default class that loads the
module bootstraps? I'm guessing it's a Zend_Loader_Autoloader_Resource.
But that could just be my ignorance. ;)

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Hector Virgen]

You might want to use a front controller plugin to handle this. The plugin
could inspect the route prior to dispatching (using the routeShutdown()
hook) and if the detected module is disabled it could forward the request to
the error controller.

--
*Hector Virgen*
Sr. Web Developer
http://www.virgentech.com

[Simon Walter]

On 05/05/2011 00:27, Hector Virgen wrote:
> You might want to use a front controller plugin to handle this. The plugin
> could inspect the route prior to dispatching (using the routeShutdown()
> hook) and if the detected module is disabled it could forward the request to
> the error controller.

Using a front controller plugin to remove the module was what I was
going to do, but that means that rather preventing a module from being
bootstraped, I'm only disabling it after it has been bootstraped. I
supposed the performance would not make that much difference esp if most
modules are enabled. Looking into it, it might be the only practical way
for now, but I'd like to consider alternate approaches at least briefly.

Perhaps I can extend: Zend_Controller_Front - the addModuleDirectory
method to be specific.

If I omit the following lines from my application.ini file, will calling
$front->addModuleDirectory($path) do the same thing:

resources.frontController.moduleDirectory = PATH
resources.modules = ""

AFAIK, the above two lines are responsible for module autoloading. Of
course it would be nice to be able to use the application.ini file and
just override what ever method is responsible for loading the modules.

addModuleDirectory looks like it iterates  over the dirs and adds the
modules' controller dir to the front. However, I see nothing about the
module's bootstrap. The init method of Zend_Application_Resource_Modules
looks like it handles bootstraping the module. From reading Matthew's
blog, I understand the bootstraping of the module happens before
routing. So perhaps there is more than one method I need to override. I
read about how since Zend_Controller_Front is a singleton, it's a bad
idea to extend it.

3 questions:

1. Does the resource loader internally call
$front->addModuleDirectory($path) for the application.ini line
"resources.frontController.moduleDirectory = PATH"?

2. If I prevent a module controller dir from being added in
addModuleDirectory, will this prevent bootstraping the module? Or will I
need to override another method elsewhere?

3. Is there a way to specify my own front controller class without
resorting to overriding the default one (like the setBootstrap method)?

Any advice is welcome! Thanks!

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Gregory]

Instead of overriding the FrontController itself, you could override
the Front Controller bootstrap resource
(Zend_Application_Resource_Frontcontroller) - it should be possible to
specify the dir location for your overriding resources. Then in that
custom front controller resource class, it could be possible to
override the init() method to manipulate the controllerdirectory array
prior to calling the parent init() method, eg:

My_Resource_Frontcontroller
  extends Zend_Application_Resource_Frontcontroller
{

public function init()
{

   //bootstrap dependencies used to figure out which modules to load
  //e.g
  $db = $this->getBootstrap()->bootstrap('db');

  //controller dirs
 $controllerdirectory = array(
   'default' => '/modules/default/controllers'
 );

  $this->setOption('controllerdirectory', $controllerdirectory);

  parent::init(); //sets desired controller dirs in the front controller

}

}

--
Greg

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Simon Walter]

On 05/05/2011 02:35 PM, Greg wrote:

> Instead of overriding the FrontController itself, you could override
> the Front Controller bootstrap resource
> (Zend_Application_Resource_Frontcontroller) - it should be possible to
> specify the dir location for your overriding resources. Then in that
> custom front controller resource class, it could be possible to
> override the init() method to manipulate the controllerdirectory array
> prior to calling the parent init() method, eg:
>
> My_Resource_Frontcontroller
>    extends Zend_Application_Resource_Frontcontroller
> {
>
> public function init()
> {
>
>     //bootstrap dependencies used to figure out which modules to load
>    //e.g
>    $db = $this->getBootstrap()->bootstrap('db');
>
>    //controller dirs
>   $controllerdirectory = array(
>     'default' =>  '/modules/default/controllers'
>   );
>
>    $this->setOption('controllerdirectory', $controllerdirectory);
>
>    parent::init(); //sets desired controller dirs in the front controller
>
> }
>
> }

Thanks Greg, that looks like it could work. Where would I specify to use
my class (My_Resource_Frontcontroller) instead of the default
(Zend_Application_Resource_Frontcontroller)?

I read here:
http://blog.philipbrown.id.au/2009/06/extending-zend-framework-application-resource-plugins/
and here:
http://blog.madarco.net/327/how-to-make-your-own-zend-framework-resource-plugin/
that I should add something like this to my application.ini file:

pluginPaths.My_Resource_Frontcontroller=  "My/Resource/Frontcontroller"

I also read elsewhere that the name of the resource plugin class must
just end in "Frontcontroller" in order it to be used for that resource.

Is that correct?

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Hector Virgen]

The "pluginPaths" option allows you specify *prefixes* to your bootstrap
resource plugins. So you'll want something like this:

pluginPaths.My_Resource =  "My/Resource"

And you would create your resource plugin here:

My/Resource/Frontcontroller.php

And the class would look something like this:

class My_Resource_Frontcontroller extends
Zend_Application_Bootstrap_Resource_Frontcontroller
{
    public function init()
    {
        parent::init();
    }
}

You'll also need to ensure that the class can be autoloaded. In this case,
you'll need to add this line to your application.ini:

autoloadernamespaces[] = "My_"

And lastly the directory that contains the "My" directory should be in your
include path. One such place might be the "library" folder in your
application.

I hope this helps!

--
*Hector Virgen*
Sr. Web Developer
http://www.virgentech.com



On Thu, May 5, 2011 at 4:35 AM, Simon Walter <[hidden email]> wrote:

> On 05/05/2011 02:35 PM, Greg wrote:
>
>> Instead of overriding the FrontController itself, you could override
>> the Front Controller bootstrap resource
>> (Zend_Application_Resource_Frontcontroller) - it should be possible to
>> specify the dir location for your overriding resources. Then in that
>> custom front controller resource class, it could be possible to
>> override the init() method to manipulate the controllerdirectory array
>> prior to calling the parent init() method, eg:
>>
>> My_Resource_Frontcontroller
>>   extends Zend_Application_Resource_Frontcontroller
>> {
>>
>> public function init()
>> {
>>
>>    //bootstrap dependencies used to figure out which modules to load
>>   //e.g
>>   $db = $this->getBootstrap()->bootstrap('db');
>>
>>   //controller dirs
>>  $controllerdirectory = array(
>>    'default' =>  '/modules/default/controllers'
>>  );
>>
>>   $this->setOption('controllerdirectory', $controllerdirectory);
>>
>>   parent::init(); //sets desired controller dirs in the front controller
>>
>> }
>>
>> }
>>
>
>
> Thanks Greg, that looks like it could work. Where would I specify to use my
> class (My_Resource_Frontcontroller) instead of the default
> (Zend_Application_Resource_Frontcontroller)?
>
> I read here:
> http://blog.philipbrown.id.au/2009/06/extending-zend-framework-application-resource-plugins/
> and here:
> http://blog.madarco.net/327/how-to-make-your-own-zend-framework-resource-plugin/
> that I should add something like this to my application.ini file:
>
> pluginPaths.My_Resource_Frontcontroller=  "My/Resource/Frontcontroller"
>
> I also read elsewhere that the name of the resource plugin class must just
> end in "Frontcontroller" in order it to be used for that resource.
>
> Is that correct?
>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>