ghola wrote > Maybe my initial question was not very good at conveying the actual issue. > Bootstrapping can be a resource intensive process. Bootstrapping modules > that won't be used for the current request is plain inefficient. Even if > the modules are more granular like you mention, it doesn't mean that they > should all load for each request. > > In ZF1 this indiscriminate boostraping was an issue too. As such i > implemented a second boostraping layer after routing was performed because > at that time i could obtain the name of the module that was being loaded > (similar to this: > http://binarykitten.com/zend-framework/296-active-module-config-v2.html). > I had hoped that this was somehow solved in ZF2 since it's developers seem > more preoccupied with it's performance than in ZF1 (one of the actual > reasons for the rewrite). So in my mind, one solution was be to allow per > route configuration since routing determines the actual module that is > going to be used (although i agree that it might not be the brightest of > ideas).
Ok now I get it what you meant. I think you've misunderstood the concept of ZF2 architecture in terms of using resources. Loading modules or making them active in application config means loading modules configurations only. These btw can be easily cached after the first request. ZF2 is event driven which means that by using Dependency Injection, Event and Service Managers and some of your custom factories in each of your Module's config you are creating mappings to say when and where your resources(like Plugins, Controllers, Helpers or Models) are injected and instantiated at the time they are used. That in fact is happening on certain routes that you setup as well as you know. ----- Cheers, -- Luke Mierzwa -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/ZF2-per-route-or-module-configuration-tp4656844p4656953.html Sent from the Zend Framework mailing list archive at Nabble.com. -- List: [email protected] Info: http://framework.zend.com/archives Unsubscribe: [email protected]
