Hi all, I have a similar question here: http://groups.google.com/group/symfony-users/browse_thread/thread/54f3c35dfe5bba4c/291cbfd5a26275ec?show_docid=291cbfd5a26275ec
<http://groups.google.com/group/symfony-users/browse_thread/thread/54f3c35dfe5bba4c/291cbfd5a26275ec?show_docid=291cbfd5a26275ec>Where can I find sufficient documentation describing service scoping. I couldn't find any in the current documentation (the book) on symfony.com. Thank you. On Thu, Mar 17, 2011 at 05:22, Gustavo Adrian <comfortablynum...@gmail.com>wrote: > Thanks a lot for your help Christophe! It's really much clearer now. I'll > take a look at the request service to get more knowledge about custom > scopes. > > > Best regards. > > > On Thu, Mar 17, 2011 at 12:12 AM, Christophe COEVOET <s...@notk.org>wrote: > >> Le 17/03/2011 04:02, Gustavo Adrian a écrit : >> >> Hi Christophe, >>> >>> But having a container-scoped service ("module") that has either a >>> container-scoped service "service" or a prototype-scoped service "service" >>> is the same thing, and is valid in both cases, at least in this particular >>> case, as my "module" service will always have only one instance of >>> "service". So when I get the "module" service using "$container->get( >>> 'module' );" I know it will have always the same instance of "service". It >>> can't have a different instance each time I get the "module" service, but it >>> doesn't mean it's wrong. Even if both had a scope "prototype" would still be >>> correct, because each instance of "module" would have one instance of >>> "service". I guess that's why exists the "strict" attribute to bypass the >>> error? for this use cases? If that's the case then I only have to add that >>> attribute. But I prefer to ask so I'm sure I'm not misunderstanding >>> something. >>> >> the scope instance mean "a new instance each time you use it" so the >> strict behavior is to use a new "service" each time the "module" uses it >> (which is not possible if the "service" instance is injected when building >> the "module"). And yes, this is what strict="false" is for. >> >> >>> The real problem (at least in this particular case) would be in the other >>> way around. If my "module" were prototyped-scoped and my "service" were >>> container-scoped, then I would have a global "service" with its state shared >>> between all my "modules", so the state of the "service" wouldn't be >>> reliable. What I didn't try is if this throws the same error. I guess in >>> some use case it could be valid too. So it really depends on the use case. >>> >> The service shared between all modules is reliable if th service is >> intended to use always the same instance (which is the case for a >> container-scoped) >> >> >>> In brief, the scope verifies if a service is really instantiated the way >>> it defines it, right? meaning, if a service has a scope "prototype", but its >>> contained in a service with scope "container", knowing that in each call to >>> "get" on the container-scoped service won't be a new instance of the >>> prototype-scoped service, it throws an error. The problem seems to be with >>> services like my "service", which is valid in both cases, contained in a >>> container-scoped service, or a prototype-scoped service, which is solved >>> disabling the "strict" attribute. >>> >>> Does any of what I said make sense? It's better to learn this stuff now >>> than when it's too late :) >>> >>> Oh, and one more question. Container scope means only one instance. >>> Prototyped means a new instance each time you get the service. What I don't >>> know is: How does the custom scopes work? >>> >> There is one "custom" scope defined by the core: the "request" scope. The >> validity of the scope is the request, which means that a new instance of the >> service will be created if you do a subrequest (the best example of >> request-scoped service is the "request" service itself). >> >> You can enter a custom scope by using $httpKernel->enterScope("my_scope") >> and leaving it by using $httpKernel->leaveScope("my_scope") where >> $httpKernel is the http_kernel service. >> >>> >>> >>> >>> Thanks in advance. >>> >>> >>> >> -- >> Christophe | Stof >> >> -- >> 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 users" group. >> To post to this group, send email to symfony-users@googlegroups.com >> To unsubscribe from this group, send email to >> symfony-users+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/symfony-users?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 users" group. > To post to this group, send email to symfony-users@googlegroups.com > To unsubscribe from this group, send email to > symfony-users+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-users?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 users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
