I already got an implementation, you can have a look on my Github account:
http://github.com/loicfrering/losolib/tree/master/src/LoSo/Symfony/Component/DependencyInjection/Loader/
.
I did not mention in my example but you can of course define all the
parameters supported by the ContainerBuilder, ex:
/** @Service("service.id") */
/** @Service(name="service.id", shared=false, tags={{name="my.tag"}}) */
It also supports parameters injection via @Value:
/** @Value("my.parameter") */
By overloading the configuration I just mentioned that it could be possible
when you want to unit test your controller to inject a mock service instead
of the real implementation as long as testing with the real implementation
means already be doing integration tests. This overloading is "just"
defining a service definition with the same id as another that will be
loaded when tests are run.
On Thu, Sep 23, 2010 at 3:38 PM, Bulat Shakirzyanov <[email protected]>wrote:
> Loïc,
>
> I was thinking about Annotation Loader for DIC for quite some time now,
> inspired mainly by Google Guice.
> Your example seems interesting, how do you see getting the service back
> from container?
> I think your example is missing service ids, and should really look like
> http://gist.github.com/593607
> As for testing, I don't think its even necessary to overload container
> there.
> Remember, the purpose of DI is to let you instantiate small portions of
> your app, without the container.
>
> <http://gist.github.com/593607>
>
> On Thu, Sep 23, 2010 at 9:26 AM, Yuen-Chi Lian <[email protected]> wrote:
>
>> Hi Loïc,
>>
>> +1 for Annotation based DIC setup. :) But of course it can't be a runtime
>> thing, so it will be a Dumper's job to address these annotations. Let me
>> know if am wrong.
>>
>> Can you give some elaboration on the idea of overloading annotation config
>> in a config file?
>>
>> For my experience, I usually write unit tests without having container
>> involved (to eliminate the bootstrap/teardown of contexts), unless the
>> dependency has grown too big to be handled in a test class. But so far, I
>> haven't faced the situation to overload configurations (be it annotated or
>> not), because test class usually holds its own context/scope/definition,
>> unless you are speaking about shared context happens usually in functional
>> tests, for that case, it can be overcome by separating your definition files
>> or include/exclude filters in reading annotated classes.
>>
>> Let me know if I am getting you right.
>>
>>
>> Yuen-Chi Lian | www.yclian.com
>> "I do not seek; I find." - Pablo Picasso
>>
>> On Thu, Sep 23, 2010 at 8:04 PM, Loïc Frering <[email protected]>wrote:
>>
>>> I am also for letting the controllers be managed by the DIC, it will
>>> increase testability and flexibility by letting the controller declare
>>> his dependencies instead of fetching them directly through the
>>> container. It is the container's job to inject their dependencies to
>>> the controllers.
>>>
>>> By the way I quite agree that declaring each controller in a
>>> configuration file is not user-friendly particularly for beginners. As
>>> I already said to Fabien on Twitter, I think that an annotation loader
>>> for the DIC would allow a quite easy configuration for our services
>>> and controllers (as services managed by the DIC). Let's see an
>>> example: http://gist.github.com/593514.
>>>
>>> For unit testing purpose, we could also easily inject mock objects
>>> instead of standard implementation by overloading annotation
>>> configuration in a config file for the testing environment.
>>>
>>> What do you think about it?
>>>
>>> On 23 sep, 13:11, Bulat Shakirzyanov <[email protected]> wrote:
>>> > Wow! Thank you, Fabien, for adding it. And thanks everyone else for
>>> > supporting it. I would say that I am not the fan of controllers *not*
>>> being
>>> > a service, but I can definitely see how this can cause confusion,
>>> especially
>>> > for people that are used to work with conventional frameworks. And
>>> having
>>> > more options probably can't really hurt. Thanks again everyone.
>>> > On Sep 23, 2010 6:57 AM, "Lukas Kahwe Smith" <[email protected]>
>>> wrote:
>>>
>>> --
>>> 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]<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]<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]<symfony-devs%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>
--
Loïc Frering
[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
