Scope specific DIC

[Josiah]

Almost every time that I have had a service which is dependant on the request you need to inject the entire container. The odd part is that these services are usually very lightweight and simple functionality.

For example, lets say that I want to create a KnpMenu voter which looks at the current URI of the request and then votes for the current menu item. Because the knp_menu.matcher service isn't in the request scope, I will create a scope widening injection error if I tag my request service with knp_menu.voter.

Ideally I should be able to tag a service which is dependant on request with knp_menu.voter and have it only be injected into knp_menu.matcher when the DIC is in the request scope.

I am happy to work on a PR to implement this but it would be good to know if there is anything that would stop this kind of functionality from being accepted first.

[Josiah]

I gained a better understanding of posts from the How to work with Scopes cookbook entry so I realise that the issue is a bit more complex than I first understood.

It would still be great to be able to manage references to narrower scopes without injecting the entire container. I propose the following:

<service id="example" class="%example.class%">
    <argument>Foo</argument>
    <argument>Bar</argument>
    <!-- Called on entry into the 'request' scope -->
    <call method="setRequest" scope="request">
        <argument id="request" type="service" />
    </call>

    <!-- Called on initial setup and exit from the 'request' scope -->
    <call method="setRequest"><argument /></call>
</service>

This would allow controlled support for narrower scopes without needing to inject the entire container. The service would be responsible for managing its own behaviour outside the request scope.

[bamarni]

From what I understand about the container, to implement your suggestion, it would need to iterate over the already created services of a given scope and call a method instead of just removing them like it is currently, I don't think it's possible because at this step service are just some runtime classes agnostic about any definition instructions.

IMO for your situation passing the container is a good solution, because you can't really match with sub requests as uri are internal stuff.
BTW there is a pending PR for an uri voter on knp menu bundle, wich I hope will be merged soon :) :
KnpLabs/KnpMenuBundle#133

[schmittjoh]

@Josiah, your second solution sounds good.

If you work on an implementation, please keep in mind that performance is a huge concern when modifying the runtime parts of the DIC.

[fabpot]

Anyone working on an implementation? It sounds like a good addition for Symfony 2.2.

[stof]

this looks indeed useful

[Josiah]

I started looking into it but I got sidetracked.

It would be fairly easy to implement should a change in scope trigger transitions for all services with transitions in them, however this could slow down scope changes drastically.

I'm trying to think of a way of making the scope transitions lazy so that they are only effected when a service is referenced (in the get method of the container). However I probably won't have time to get stuck back into this PR for a few weeks.

[stof]

@Josiah It should not be done in the get method, as this would not work for services injected inside anoher service (which is the main use case as services accessed only at runtime can generally be moved to the request scope in such case)

[Josiah]

That's a good point. I might see about implementing something that just manages the transitions between scopes for now, and then look at ways to improve performance once its done.

Ideally any performance hit won't happen unless transitions have been defined in the container anyway.

[fabpot]

Adding this with the current architecture is probably not possible without adding something "new". Managing transitions could be done in the enterScope and leaveScope methods, but the problem is that when you enter the scope, some of the services might not be available yet. Here is a snippet of code from the kernel:

$this->container->enterScope('request');
$this->container->set('request', $request, 'request');

[merk]

Could something like work?:

$this->container->openScope('request');
$this->container->set('request', $request, 'request');
$this->container->enterScope('request');

[fabpot]

Ok, I've found a workaround which should be doable without changing anything. I have a working prototype when not using the dumper (which should be easy to do after everything work for the main ContainerBuilder class). I'm going to create a pull request later on.

[Crell]

fabpot, any sign of the prototype? We'd love to see what you're cooking up. :-)