On 4/14/11 1:25 PM, Johannes wrote:
Just want to add some more options here which I mentioned on the
respective pull requests already:
5) Disabling interface injection on a per-method basis:
foo:
disable_interface_injection:
setContainer: true
6) Prepending calls from interface injection instead of appending them
7) Making it easier to disable interface injection globally
$passConfig->disableInterfaceInjectionPass()
IMO 6) is easiest to implement, and is consistent with what we already
do for definition inheritance.
all options except 6 seems overcomplicated to me.
Fabien
Johannes
On Apr 14, 12:03 am, Lukas Kahwe Smith<[email protected]> wrote:
Aloha,
Whenhttps://github.com/symfony/symfony/pull/535was merged I noticed that this
was causing issues when I tried to set an alternative service container,
because ContainerAwareInterface implementing classes would now get the service
container injected after my custom service container, effectively overwriting
my customer container.
I created a quick fix which was reverted for good reasons.
I have created two additional pulls which in my opinion fix the issue, which is
being able to override interface injection on a per service basis:
1)https://github.com/symfony/symfony/pull/544
This pull effectively disables interface injection whenever a service has any
explicit call's configured.
liip_hello.phpcr.controller:
class: Liip\HelloBundle\Controller\PHPCRController
calls:
- ['setContainer', [ @liip_hello.container ] ]
2)https://github.com/symfony/symfony/pull/547
This pull adds a new flag to determine if interface injection should be
disabled for this service
liip_hello.phpcr.controller:
class: Liip\HelloBundle\Controller\PHPCRController
interfaceInjectionEnabled: false
calls:
- ['setContainer', [ @liip_hello.container ] ]
Another approach would be to stop using interface injection in core entirely.
However I think the same issues will then be caused by 3rd party bundles. I
think the end user defining a service should always have final control over
what gets injected. For the same reason we do not inherit stuff like tags's
which cannot be removed in a service definition.
3) Now Johannes does not seem to like either of the proposed solutions. He
indicated on IRC that he would prefer a more granular solution, where there
would be an optional flag on a per method basis for disabling interface
injection.
I could it would look like something like the following, where the third element in the
array would define that no "setContainer" calls should be added via interface
injection.
liip_hello.phpcr.controller:
class: Liip\HelloBundle\Controller\PHPCRController
calls:
- ['setContainer', [ @liip_hello.container ], true ]
4) Jeremy was suggesting a setting that would determine some conflict
resolution
strategyhttps://github.com/symfony/symfony/pull/544#issuecomment-995402
Personally I think that interface injection is nice syntax sugar, but its not
critical to have. However it should definitely not get in the way of defining a
service with custom dependencies. Of course I can always change the code to not
implement the interface, but that kinda perverts the entire idea of dependency
injection. So I think its critical that we fix the current situation.
regards,
Lukas Kahwe Smith
[email protected]
--
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
