-- Deanna Bonds <[email protected]> wrote (on Thursday, 14 May 2009, 03:37 PM -0500): > Matthew Weier O'Phinney wrote: > > Push their initialization into a different location. For instance, you > > could create one or more front controller plugins that, based on the > > module or controller detected, initialize the session, or the database, > > or authentication session, or acls -- and pull configuration from the > > bootstrap, via the front controller: > > > > $bootstrap = > > Zend_Controller_Front::getInstance()->getParam('bootstrap')); > > > > Alternately, initialization can be done within individual > > controllers, pulling the configuration from the bootstrap () in > > order to get necessary settings: > > > > $bootstrap = $this-> getInvokeArg('bootstrap') > > Question out of curiosity. We have the global application object > hanging out there. It has to be global by the framework design. Can we > not use that to bootstrap components, and/or get the config options?
Arg! You CC'd me, and I responded off-list. We're moving away from singletons in the framework. Our experience in testing ZF, and the experience of those using ZF and attempting to test their applications, is that singletons are a nightmare. As such, Zend_Application itself is *not* a singleton, and the registry of initialized resources inside of the bootstrap is not either. That said, we're pushing the bootstrap *into* the front controller -- which *is* a singleton, so you can always grab it, and its registry, via the front controller. That's what the first example I provided above displays. -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/
