Personally, I don't think it's a super idea. Most of the time, commands should be lightweight.
If there is too much code in a command, that's a good indicator to extract it to a dedicated class (which then can be a service). This also makes code easier re-usable as you decouple your code from the input/output interfaces. Your tests will benefit from this as well. Cheers, Johannes On Sun, Dec 9, 2012 at 11:25 PM, Lukas Kahwe Smith <m...@pooteeweet.org>wrote: > > 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 > -- 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
