Controllers are a typical use case where I would use the recently added
property injection:
<service id="base_controller" abstract="true">
<property name="securityContext" type="service" id="security.context" />
</service>
<service id="some_controller" parent="base_controller" class="MyClass">
</service>
abstract class BaseClass
{
protected $securityContext;
}
class MyClass extends BaseClass { }
As far as Spring is concerned, the closest that I'm aware of to interface
injection is auto-wiring:
http://static.springsource.org/spring/docs/3.0.x/reference/beans.html#beans-factory-autowire
Johannes
On Tue, Apr 19, 2011 at 11:02 PM, Jeremy Mikola <[email protected]> wrote:
> The complete removal of it is rather unfortunate.
>
> I can only speak for OpenSky's code base, but we've relied on it for our
> controller services. Having our controllers implement things like
> RouterAwareInterface, SecurityContextAwareInterface, and the like (all
> things that the base, non-service controller class depends on), allowed us
> to embrace DRY and avoid:
>
> - Many, many constructor arguments
> - Many <call> blocks for setter methods
>
> Without interface injection, the configuration for controller services is
> going to become rather hellish (at least for very large projects).
>
> It's late in the Symfony2 development lifecycle and I admittedly have not
> closely followed the argument here, but are there no solutions to be found
> in Spring's or Google Guice's implementation of interface injection?
>
>
> On Tue, Apr 19, 2011 at 4:51 PM, Fabien Potencier <
> [email protected]> wrote:
>
>> After a short discussion with Bulat, I propose to remove interface
>> injection from the DIC altogether. The added benefit is quite small and
>> it's not easy to make it for edge cases like the one exposed by Lukas.
>> So, instead of adding even more complexity to a very small feature,
>> let's remove it altogether.
>>
>> Fabien
>>
>> --
>>
>> Fabien Potencier
>> Sensio CEO - Symfony lead developer
>> sensiolabs.com | symfony.com | fabien.potencier.org
>> Tél: +33 1 40 99 80 80
>>
>>
>> On 4/17/11 4:39 PM, Bulat Shakirzyanov wrote:
>>
>>> Good idea but it won't work with not frozen containers
>>>
>>> Sent from my Nexus One
>>>
>>> On Apr 17, 2011 10:23 AM, "Jordi Boggiano" <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> > On 17.04.2011 15:59, Lukas Kahwe Smith wrote:
>>> >> No, I do not want to disable injection for an entire interface.
>>> >> All I want is to be able to decide on a per service basis what to
>>> inject without syntax sugar features from limiting me.
>>> >> At the same time I do not think it makes sense to add a bazillion
>>> new flags and options to handle disabling these syntax sugar features if
>>> they cause a problem.
>>> >>
>>> >> This is why I (and I guess also Bulat) favors the simplicity of a
>>> per service flag (rather than a per method/interface flag etc).
>>> >>
>>> >> So yes, the point isn't that I want to just blindly disable all
>>> interface injection for a service, but that I think trying to do it more
>>> granular is overboard and for the few (but important) cases where I run
>>> into issues with interface injection I am prepared to manually deal with
>>> it by then manually setting the proper services to call.
>>> >
>>> > +1 on this
>>> >
>>> > Another approach though, which might conciliate everyone (riiight):
>>> >
>>> > services:
>>> > foo:
>>> > class: lala
>>> > interfaces:
>>> > Some\Interface: @otherservice
>>> >
>>> > Basically there you could override which services are taken for which
>>> > interface, on a per-service basis.
>>> >
>>> > 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 <http://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]
>>> <mailto:[email protected]>
>>>
>>> > To unsubscribe from this group, send email to
>>> > [email protected]
>>> <mailto:symfony-devs%[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
>>>
>>
>> --
>> 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
>>
>
>
>
> --
> jeremy mikola
>
> --
> 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
