On 24.02.2011 09:46, John Wards wrote: > However I have this nagging worry, I have no idea what I have done or > why I have done it.
Ack. While I fully understand the scope stuff now, I still agree it's confusing to tell people to do something without really being able to explain them what they're doing (because that requires a moderately deep understanding of the framework, which I don't think newcomers will have). That just highlights the need for a default "request" scope imo. (More on that at the end of the mail) Anyways, to try and answer you: The request service is changing over time because you can have sub-requests (if you call render() in a template for example). That sub-request will set the request service to a new Request() instance while it runs, and put back the master request in place when it's finished. This means that if you injected the master request instance in your controller, and the sub-request triggers the same controller, your controller will not be re-instantiated, and it will be executed with a request object that is the master instead of the sub request. That is very wrong. To avoid this, the scopes were introduced. Now any service that is in the request scope will be re-instantiated once per request/sub-request/sub-sub-request/.. Since the request service itself is inside the request scope, the DIC tells you that injecting it in your container-scoped (the current default) controller service is not a good idea because you risk hitting the above issue. So you're forced to move your controller to the request scope as well, and then all is well again, it'll be instantiated once for every request, avoid any problem. I hope this is a bit more clear :) TL;DR: So what this means if we changed the default scope to request is that basically when you have sub-requests, you'll use more memory/cpu since you instantiate all your userland services twice, unless you specifically mark them as having the container scope. Of course all (well most) core services would be set to the container scope, so I don't think this performance issue would matter much. Performance conscious people will probably put varnish on top anyway and in this case you seldom have internal sub-requests I believe. Cheers -- Jordi Boggiano @seldaek :: http://seld.be/ -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
