On 02.11.2010, at 17:09, ryan weaver wrote: > Hey guys > > After talking to a few people at zendcon (not Fabien yet, he's elusive), I > feel that this is cool, but heavy-handed and probably unnecessary. I > understand that we're trying to make sure that bundles are properly reusable > and overrideable, but with a vibrant community, I think we should consider > solving this in bundle code and then setting these as best practices. With > github, we now have a lot more power in "correcting" poor practices in > bundles. If there are solutions that would be good for the core, they'll > eventually grow naturally from our best practice" code.
i still think that the context approach is viable. but my pet peeve is the practice of injecting the container and then hardcoding service names inside the controller. this kills off a lot of extensibility that was gained by having a DIC to begin with. i see three main issues we need to solve: 1) how to ensure that every controller can be customized with specific services injections (aka being able to inject a swiftmailer based emailer in one controller and a zeta components based mailer in another one) 2) how to handle injection of services into a controller which rarely requires the given service (f.e. email) 3) how to handle injection of services dynamically (f.e. injecting a different templating/reponse services based on the requested format) For 1) the solution to me seems to simply stop injecting the container. The only other solution is to make the names configurable either via the proposed "context" support or a more simplistic approach like: https://github.com/lsmith77/symfony/commit/ac9e5a7a9fe050ae0c3ae1397fae1f4287e1a6a8 For 2) here one approach is injecting the container. Another approach is to make sure that every services is cheap to instantiate or to add a wrapper of some sort around services that are too heavy. For 3) one approach here is context support or the above mentioned simplistic alternative approach: https://github.com/lsmith77/symfony/commit/ac9e5a7a9fe050ae0c3ae1397fae1f4287e1a6a8 Another approach would be to for the cases where the service is to be dynamic to use another wrapper (or DIC) around the different possible services. Finally we might just determine that there are only a few cases where such a feature will likely be used and find dedicated solutions for this (like for the format stuff add some optional agavi-view like solution) regards. Lukas Kahwe Smith m...@pooteeweet.org -- 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 symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
