I needed this, and it seemed generically useful enough to have in Drush core (there is a suggestion for it at #582598: Submodule names in module package need guessing). The doxygen is below.
Let me know if you have any thoughts - the main things I am not sure about are if the $final_options concept is useful (or if we should limit it to a single built in "Done" option), as well as if we should try and cover eventualities by adding a $callback parameter (this could allow callers to alter the $selections, and perhaps even $options mid-stream in the process. I am thinking this could be handy where there are dependencies of some kind implicit in the options). If I don't hear anything in the next 2 or 3 days I am planning on committing as is.
/**
* Ask the user to select multiple items from a list.
* This is a wrapper around drush_choice, that repeats the selection process,
* allowing users to toggle a number of items in a list. The number of values
* that can be constrained by both min and max: the user will only be allowed
* finalize selection once the minimum number has been selected, and the oldest
* selected value will "drop off" the list, if they exceed the maximum number.
*
* @param $options
* Same as drush_choice() (see above).
* @param $defaults
* This can take 3 forms:
* - FALSE: (Default) All options are unselected by default.
* - TRUE: All options are selected by default.
* - Array of $options keys to be selected by default.
* @param $prompt
* Same as drush_choice() (see above).
* @param $label
* Same as drush_choice() (see above).
* @param $mark
* Controls how selected values are marked. Defaults to '!value (selected)'.
* @param $min
* Constraint on minimum number of selections. Defaults to zero. When fewer
* options than this are selected, no final options will be available.
* @param $max
* Constraint on minimum number of selections. Defaults to NULL (unlimited).
* If the a new selection causes this value to be exceeded, the oldest
* previously selected value is automatically unselected.
* @param $final_options
* An array of additional options in the same format as $options.
* When the minimum number of selections is met, this array is merged into the
* array of options. If the user selects one of these values and the
* selection process will complete (the key for the final option is included
* in the return value). If this is an empty array (default), then a built in
* final option of "Done" will be added to the available options (in this case
* no additional keys are added to the return value).
*/
| Comment | File | Size | Author |
|---|---|---|---|
| drush_choice_multiple.patch | 4.23 KB | owen barton |
Comments
Comment #1
greg.1.anderson commentedI think that entering a csv list of option numbers would be more usable than mark / confirm / cancel in a loop.
See also #1007148: Make drush_choice and drush_print_file respect non-interactive modes. Overall, I think this is a good idea.
Comment #2
moshe weitzman commentedGreg's idea sounds better to me as well. Am open to discussion here.
Comment #3
owen barton commentedI agree CSV would be preferable for many kinds of choices, certainly worth adding. I think we may still sometimes need some kind of refinement/confirmation loop of the kind implemented in my patch though, especially if you have min/max constraints.
In terms of implementation, I guess the main question is if we should (a) keep the basic drush_choice_multiple in the patch, but extend drush_choice to add optional CSV processing (perhaps this could be a lightweight form of drush_choice_multiple when you don't need refinement/confirmation), (b) drop drush_choice_multiple completely, and build more functionality into drush_choice or (c) add the basic text input code (and CSV stuff) into drush_choice_multiple directly (and not build on drush_choice).
Thoughts?
Comment #4
greg.1.anderson commentedI don't think that we should put loops or min/max constraints in drush core until we need that functionality for a core command.
I'm indifferent to extending drush_choice vs. making drush_choice_multiple, so long as the former does not involve changing the function signature of drush_choice (i.e., don't change existing parameters, only add new parameters with default values). If implementing that is not clean, then make drush_choice_multiple.
Comment #5
moshe weitzman commentedI'm also indifferent about implementation. I'll just trust Owen to sort it out.
I do think loop and max/min are core worthy. Even if no core command uses them right now, they will be much appreciated in Contrib.
Comment #6
greg.1.anderson commentedI was thinking about the implementation of the loop and min/max, and think that everything could easily be inserted into drush_choice without too much code, so I agree w/ moshe.
Comment #7
moshe weitzman commentedWe can commit this as is for Drush4. As along ass Owen is comfortable with it.
Comment #8
owen barton commentedI would like to add the ability to specify as CSV...I'll add that and commit.
Comment #9
greg.1.anderson commentedThis can go in drush-4 any time, so long as the behavior and signature of drush_choice stays the same. csv would be nice.
Comment #10
owen barton commentedCommitted as is for now, leaving as postponed so to help us remember to add CSV later on
Comment #11
greg.1.anderson commentedI think that "active" is a better status for now.
Comment #12
drzraf commentedsee #1007578: Add the ability to enter a csv list of items to drush_choice_multiple about the ability to select All/None which is not far from what is requested here.
Comment #13
greg.1.anderson commentedThis issue was marked
closed (won't fix)because Drush has moved to Github.If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to
closed (duplicate).Please ask support questions on Drupal Answers.