On Dec 9, 2012, at 20:42 , Paul Seiffert <paul.seiff...@gmail.com> wrote:
> Hi, > > this e-mail is a follow-up to a discussion I had on Twitter with @lsmith. It > started with my simple question, whether somebody had implemented console > commands as services before. At that time I was starting to work on some > console commands by first adding unit tests and refactor them in the second > step. Trying to make them testable, I immediately wanted to define them as > services. After some research I found this article > (http://avalanche123.com/blog/2010/10/15/symfony2-console-commands-and-dic/) > from October 2010, but I never found the feature's implementation. > Yesterday night, I published the console-extra-bundle > (https://packagist.org/packages/seiffert/console-extra-bundle) which allows > developers to define their commands as services. Each service that is tagged > with "console.command" is considered a console command and registered at the > console application. i think is a very useful addition. i remember before 2.0 went stable Henrik was looking into this and the criticism back then was that adding more services to the DIC might cause a slow down. i think this worry is a bit overzealous. however if we leave everything as is for all current core commands and simple provide this as an option. that being said if this is a real issue, ie. the DIC getting too big, then maybe we should look into ways to tag services and then have some compiler pass that is used in a compiler pass to actually "move" the service into a separate DIC. furthermore i think we should promote the concept of multiple kernels more and encouraging developers to group services and making it possible to disable those groups. ie. a bundle would give a "commands" config option where one could disable the commands services, so that they could in turn be enabled in a separate kernel. > If you have a look at the code/docs, you might find the following disturbing: > Every bundle that wants to use command services, has to override > Bundle::registerCommands() with an empty implementation. This is required > because Symfony's default implementation of reigsterCommands() iterates over > all command classes from <bundle-path>/Command/ and registers object created > from these classes as commands. If you don't override this default > implementation, commands that reside in <bundle-path>/Command/ and are > defined as services, would be registered twice… > In my opinion, registering commands from a certain directory automatically is > a pretty strict convention. However, we could weaken this convention by > adding a method Bundle::autoRegisterCommands(), which returns true by default > and can be overridden in order to specify whether or not commands should be > loaded from <bundle-path>/Command/ ? i guess using a different subnamespace than "Command" would also work. > Another issue regarding this feature is whether it should be part of one of > the better known bundles like FrameworkBundle and FrameworkExtraBundle. i think this should go into FrameworkBundle 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
