> > 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") */ > > That's great, I'll take a look, thanks
> 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. > > That's one possibility, personally I find it abusing the DI, here's an example of what I mean - http://gist.github.com/593607#file_test.php <http://gist.github.com/593607#file_test.php>In there we don't event touch the DIC, we just get our mocks and inject them into the controller of our SUT directly > 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]<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
