Zend Framework

Zend_Application_Resource_Modules bootstraps all modules bootstraps at a single module request

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Not an Issue
  • Affects Version/s: 1.9.5
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

As noted, the modules resource bootstraps all modules, even when only a single module is requested. This looks weird, cause module specific bootstrap should be executed only when the module is in use.

In a modular application with 4 modules (default, admin, blog and news) for example, a request to http://zend-app/admin/index/index will bootstrap the 4 modules.

Additional check made at Zend_Application_Resource_Modules confirmed this behavior - checkout the foreach() starting in line 66 of Zend/Application/Resource/Modules.php.

Maybe the request above might had the default module bootstrapped (as a generic bootstrap) and only the requested module bootstrapped (as a specific bootstrap).

Is my approach correct or there is a high level need of this behavior?

Activity

Hide
Matthew Weier O'Phinney added a comment -

This will not work for the simple reason that the requested module is not known at bootstrap time; it is determined during routing.

Bootstrapping is for setting up the various dependencies necessary for the application to run. Module bootstraps are executed primarily (a) to setup autoloading, so that you can share and use resources between modules, and (b) to setup module-specific plugins.

This latter is when you should do any initialization that is module-dependent. For instance, if you need a different DB adapter or layout when a particular module is present, you would setup a routeShutdown() or dispatchLoopStarup() plugin from your module's bootstrap, that plugin would then check if the requested module matches, and then, and only then, execute those actions.

Show
Matthew Weier O'Phinney added a comment - This will not work for the simple reason that the requested module is not known at bootstrap time; it is determined during routing. Bootstrapping is for setting up the various dependencies necessary for the application to run. Module bootstraps are executed primarily (a) to setup autoloading, so that you can share and use resources between modules, and (b) to setup module-specific plugins. This latter is when you should do any initialization that is module-dependent. For instance, if you need a different DB adapter or layout when a particular module is present, you would setup a routeShutdown() or dispatchLoopStarup() plugin from your module's bootstrap, that plugin would then check if the requested module matches, and then, and only then, execute those actions.
Hide
Bruno Pirajá Moyle added a comment -

Okay, that's right.

The bootstrap should only contain calls to module's specific plugins, which in turn validates the current module - as at bootstrap time the current module is unknown.

Isn't a good idea to explicitly define this behavior in the 4.6.4 reference guide section?

Show
Bruno Pirajá Moyle added a comment - Okay, that's right. The bootstrap should only contain calls to module's specific plugins, which in turn validates the current module - as at bootstrap time the current module is unknown. Isn't a good idea to explicitly define this behavior in the 4.6.4 reference guide section?

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: