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 <[email protected]> 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 [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-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 [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-users?hl=en

Reply via email to