Re: [fw-general] Lazy Loading Resources
The Manager's primary advantage is to hold multiple configurations on tap in an easily accessible way. It's a middle road of sorts since caches are heavily context based. It's easily adapted to lazy loading but then are we not entering DI territory anyway? Paddy Sent from my iPhone On 15 Oct 2010, at 15:26, Jurian Sluiman wrote: > On Friday 15 Oct 2010 12:45:12 Matthew Weier O'Phinney wrote: >> The design of Zend_Application was to initialize resources needed on >> each request, plain and simple. >> >> What you describe is more of a Service Container and/or DI Container. >> You can actually use these _with_ Zend_Application to augment it -- a >> number of folks have injected the Symfony DI Container into >> Zend_Application in order to achieve similar results: > > This is not completely true in the case of Zend_Cache_Manager. The manger is > accompanied by Zend_Application_Resource_Cachemanger and the behaviour could > also be copied to other resources. > > Although the first advantage of the cache manager is not the lazy loading, it > is mentioned in the proposal as "second advantage". This principle could be > used for other resources like database and logs. > > Regards, Jurian > -- > Jurian Sluiman > CTO Soflomo V.O.F. > http://soflomo.com
Re: [fw-general] Lazy Loading Resources
On Friday 15 Oct 2010 12:45:12 Matthew Weier O'Phinney wrote: > The design of Zend_Application was to initialize resources needed on > each request, plain and simple. > > What you describe is more of a Service Container and/or DI Container. > You can actually use these _with_ Zend_Application to augment it -- a > number of folks have injected the Symfony DI Container into > Zend_Application in order to achieve similar results: This is not completely true in the case of Zend_Cache_Manager. The manger is accompanied by Zend_Application_Resource_Cachemanger and the behaviour could also be copied to other resources. Although the first advantage of the cache manager is not the lazy loading, it is mentioned in the proposal as "second advantage". This principle could be used for other resources like database and logs. Regards, Jurian -- Jurian Sluiman CTO Soflomo V.O.F. http://soflomo.com
Re: [fw-general] Lazy Loading Resources
-- A.J. Brown wrote (on Thursday, 14 October 2010, 05:09 PM -0400): > I've been doing some research on lazy loading resources in Zend Framework, > and it seems that the decision has been made that resources that should be > lazy loaded should not be a part of the bootstrapping mechanism. I'm not > sure that I agree with this idea, so I'd like to re-open the discussion. > > For example, I currently have code which makes use of Zend_Service_LiveDocx. > For Dependency Injection, I would rather the class be configured outside of > the methods that are calling it, so creating a resource seems to be the best > bet. However, it's a "waste of time" to initialize the LiveDocx class 99% > of the time, since only a small portion of the application uses it. In this > particular case I believe the overhead will be very minimal compared to the > added complexity/duplication of doing it any other way, but that's not > necessarily true in other cases. > > Being that resources are able to load their dependencies themselves using > the Boostrap mechanism, wouldn't it make more sense to lazy load ALL > resources by default? Of course this becomes an issue when you're using > _init functions in your Bootstrap class to configure the application, and > they don't return any resources. So, it seems that there needs to be some > distinction between initialization and resources. Or, perhaps, a > distinction between resource classes, and init functions within the Boostrap > file. > > Thoughts? The design of Zend_Application was to initialize resources needed on each request, plain and simple. What you describe is more of a Service Container and/or DI Container. You can actually use these _with_ Zend_Application to augment it -- a number of folks have injected the Symfony DI Container into Zend_Application in order to achieve similar results: * http://www.whitewashing.de/blog/articles/118 * http://blog.starreveld.com/2009/11/using-symfony-di-container-with.html * http://losohome.wordpress.com/2010/01/22/integrating-symfony-dependency-injection-service-container-with-zend-framework/ -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Re: [fw-general] Lazy Loading Resources
I agree with yo 100%. Not being able to lazy load resources doesn't make sense. There are very few resources that are required with every page load. Even the DB or View objects may not be necessary much of the time with proper caching. I created my own resource manager that creates resources only when they are requested and this handles all of my resources. I still use a bootstrap class but it requests all resources from the resource manager. Mark On Thu, Oct 14, 2010 at 3:09 PM, A.J. Brown wrote: > Hi All, > > I've been doing some research on lazy loading resources in Zend Framework, > and it seems that the decision has been made that resources that should be > lazy loaded should not be a part of the bootstrapping mechanism. I'm not > sure that I agree with this idea, so I'd like to re-open the discussion. > > For example, I currently have code which makes use of Zend_Service_LiveDocx. > For Dependency Injection, I would rather the class be configured outside of > the methods that are calling it, so creating a resource seems to be the best > bet. However, it's a "waste of time" to initialize the LiveDocx class 99% > of the time, since only a small portion of the application uses it. In this > particular case I believe the overhead will be very minimal compared to the > added complexity/duplication of doing it any other way, but that's not > necessarily true in other cases. > > Being that resources are able to load their dependencies themselves using > the Boostrap mechanism, wouldn't it make more sense to lazy load ALL > resources by default? Of course this becomes an issue when you're using > _init functions in your Bootstrap class to configure the application, and > they don't return any resources. So, it seems that there needs to be some > distinction between initialization and resources. Or, perhaps, a > distinction between resource classes, and init functions within the Boostrap > file. > > Thoughts? > -- > A.J. Brown > Software Engineer, ZCE > blog : http://ajbrown.org > talk : (937) 540-0099 > chat : IntypicaAJ > -- Have fun or die trying - but try not to actually die.
[fw-general] Lazy Loading Resources
Hi All, I've been doing some research on lazy loading resources in Zend Framework, and it seems that the decision has been made that resources that should be lazy loaded should not be a part of the bootstrapping mechanism. I'm not sure that I agree with this idea, so I'd like to re-open the discussion. For example, I currently have code which makes use of Zend_Service_LiveDocx. For Dependency Injection, I would rather the class be configured outside of the methods that are calling it, so creating a resource seems to be the best bet. However, it's a "waste of time" to initialize the LiveDocx class 99% of the time, since only a small portion of the application uses it. In this particular case I believe the overhead will be very minimal compared to the added complexity/duplication of doing it any other way, but that's not necessarily true in other cases. Being that resources are able to load their dependencies themselves using the Boostrap mechanism, wouldn't it make more sense to lazy load ALL resources by default? Of course this becomes an issue when you're using _init functions in your Bootstrap class to configure the application, and they don't return any resources. So, it seems that there needs to be some distinction between initialization and resources. Or, perhaps, a distinction between resource classes, and init functions within the Boostrap file. Thoughts? -- A.J. Brown Software Engineer, ZCE blog : http://ajbrown.org talk : (937) 540-0099 chat : IntypicaAJ
