I'm not sure if changing the default scope to "request" actually solves the problem because sooner or later people will have to learn scope anyway, so imo it would probably be best to have something in the documentation (best with some graphics, not only text if that is possible).
Fabien has mentioned this in another thread. At the moment, we can throw an error if people are doing something potentially wrong; by changing the default scope to request that would not be possible anymore. Kind regards, Johannes On Thu, Feb 24, 2011 at 10:11 AM, Jordi Boggiano <[email protected]> wrote: > 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 > -- 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
