Matthew Weier O'Phinney wrote:
[...]
Which is something I currently do via a Controller plugin, not a
solution I'm particularly happy with. Although Zend_Application does
inspire a more elegant, reusable way of implementing this, it would be
great to have a similar "standard" solution, a sort of second phase
bootstrap.
Or am I completely missing the point of Zend_Application and is there
already a better way of doing this?
You already identified the way to do this: controller plugins.
Bootstrapping is for stuff that needs to happen *on every request*.
Plugins give you the ability to determine if the given request requires
additional initialization.
One technique you can use is to instantiate a controller plugin,
register your module's bootstrap with it, and then register it with the
front controller:
[...]
Then, in your plugin, you can selectively call methods on the bootstrap
if the request matches that module.
Thank you, that really helps to confirm I'm looking in the right direction.
What I'm doing right now (I want to avoid code changes when re-using
modules as much as possible) is register a generic controller plugin for
the entire application, which at routeShutDown looks for and registers a
controller plugin for the requested module in the module directory, in a
similar way in which Zend_Application looks for and runs the a module
bootstrap.
That plugin then handles all the stuff specific for that module from
dispatchLoopStartup onwards.
Seems to work like a charm so far.
The fact that the plugin is only registered after routeShutDown is no
big deal, because that's before module specific stuff starts happening.
It also has the advantage that the controller plugins for each module
are only instantiated and registered when needed, and inside the plugins
themselves I don't need to bother with checking if the request matches
the module, because the are by nature module-specific.
Does that sound like a halfway sane solution?
R.
