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] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
