Hello,
I am trying to check out the list of modules in Commandbox and receive the following and I am not sure if this is an intentional response or a bug.
coldbox module list
Command not implemented!
Thank you for any feedback!
Ryan Hinton
That means the command is not implemented 
We stubbed out a lot of commands when we first created CommandBox but never put any code in them to actually do anything.
A command is just a CFC file. You can easily view the code for the “coldbox module list” command here (where “~” is your user’s home dir):
~.CommandBox\cfml\commands\coldbox\module\list.cfc
/**
- Description of command
**/
component extends=“commandbox.system.BaseCommand” aliases="" excludeFromHelp=false {
/**
Would be fun to try to implement some of these commands. Is there a little more info, like what you just provided, about the planned intent for the command(s)?
I love the command box help, and if it the stubbed out command’s description had some basic info about what the Ortus team had in mind for the command it might help clarify what should be built.
Thanks!
This is a good idea. To be honest, the original list of commands sprung from a large Google doc brain-dump between a number of people dreaming up all the cool things we could do with CommandBox. We only really specced out the ones we ended up doing for the first version. When I wrote the help command, I stubbed out everything in Google doc as placeholder CFCs just to see how it would all work. (The original help command output EVERY command and all its info which was WAY too much text
We discussed removing the unimplemented commands when we released but they ended up just staying there are placeholders. I’m not actually sure about all of the commands since I didn’t write most of them down on the google doc, though the majority seemed pretty self explanatory. Though, I was completely wrong earlier today about the 'coldbox compile" command
I’m not sure the best way to handle this-- we could try to go through and flesh out the documentation in the commands themselves, or we could go and create tickets for each unimplemented command in JIRA. Either way, Luis and I are unlikely to have time to do this until after Into The Box and dev.Objective() which is coming up very quickly.
Thoughts/suggestions?
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Thanks, Brad. I figured they were not built but just wanted to verify and truly know that it was intentional by you guys and not possibly some sort of conditional statement mix up or something.
I like your last discussion and it would be great to see what needs to be completed with guidelines to complete specific tasks if any of us have spare time to help.
- Ryan Hinton
Maybe a quick blog post like you have for how to submit JIRA tickets that outlines a process for validating what an un-implemented command was originally intended to would be a good guide. So in cases where someone has some time to spare and thinks a command would be worth implmenting a JIRA ticket could be created where they could submit their interpretation of the command for clarification/validation as a sort of “spec”.
Then a simple update/PR to put the link to the JIRA ticket, temporarily, in the help description of the un-implemented command could be submitted to in a sense show that the command is in-development or there is interest in implementing the command. If nothing else this allows the spec process to be crowd-sourced and anyone interested can watch the issue and contribute to the command’s development.
This way it’s not on you or Luis or who ever dreamed up the command to write the description, but rather just chime in and clarify where needed before someone implements a command.
The compile command was a perfect example of how a command yielded two completely different, intriguing and valid, interpretations. This way JIRA could be the place for little dialogue to take place before someone works on a command. This could also help make sure the command is implemented under correct namespace, etc.
Just some thoughts!