Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[Console] Show hidden commands in json & xml descriptors#21075
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
[Console] Show hidden commands in json & xml descriptors#21075
Uh oh!
There was an error while loading.Please reload this page.
Conversation
ogizanagi commentedDec 28, 2016
| Q | A |
|---|---|
| Branch? | master |
| Bug fix? | no (may be considered, but as hidden commands did not exist before 3.2, looks more like a behavior change, hence a feature) |
| New feature? | yes |
| BC breaks? | no |
| Deprecations? | no |
| Tests pass? | yes |
| Fixed tickets | #20866 (comment) |
| License | MIT |
| Doc PR | N/A |
ro0NL commentedDec 28, 2016
Nice 👍 what about |
ogizanagi commentedDec 28, 2016
Looks like an idea to me :) But I'd like to keep meaningful defaults based on the format unless the Anyway, let's first approve this one before. |
ro0NL commentedDec 28, 2016 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Technically they dont know about each other.. they should not make assumptions regarding context imo. The only context we do have is "hidden", probably meaning; dont bother the user with it. So 👍 for defaulting to false, where defaulting is needed. But i understand you actually chose to differ between XML/JSON and markdown here. Always providing the information technically in that case. I think we should do format based decision making at command level. More close to real user decision making. Although it could still be experienced counter-intuitive. No real opinion here :)
Im not sure you wanna do 2 PR's? But imo. it can be 1, doing the feature as a whole. Right now master is good (imo.); consistently hidden by default. Not sure we want this intermediate step, or as final solution for that matter, again imo. For me 👍 adding |
ogizanagi commentedDec 28, 2016 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Just waiting for some more feedbacks on this and the option suggestion. But ok, done. |
fabpot commentedDec 28, 2016
I think I'm 👎 on the |
ro0NL commentedDec 28, 2016
Sounds reasonable. But it really depends what "hidden" means. Is it only from a end-user perspective? GUI-wise? Then the initial (by now ;-)) approach makes sense. Including for technical formats, excluding for human formats. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
LGTM 👍 basically only having the console option yes/no is questionable.
Status: Reviewed
| $description =newApplicationDescription($application,$namespace); | ||
| $namespace =isset($options['namespace']) ?$options['namespace'] :null; | ||
| $showHidden =isset($options['show_hidden']) ?$options['show_hidden'] :false; | ||
| $description =newApplicationDescription($application,$namespace,$showHidden); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Getting aApplicationDescription from options looks tedious..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
What do you mean? 😕
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Descriptor::getApplicationDescription($options) could be worth it by now (2 options * 4 descriptors)
| ####`--show-hidden` | ||
| To show hidden commands |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
MaybeTo include hidden commands, it kinda implies we lose the other ones. Anyway this made me doubt between--show-hidden and--with-hidden. Im fine either way, but perhaps be explicit in its description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Why not.include indeed looks better to me :)
| * @param string|null $namespace | ||
| * @param bool $showHidden | ||
| */ | ||
| publicfunction__construct(Application$application,$namespace =null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This feature is good for sure 👍 same for updated outputs.
| newInputArgument('namespace', InputArgument::OPTIONAL,'The namespace name'), | ||
| newInputOption('raw',null, InputOption::VALUE_NONE,'To output raw command list'), | ||
| newInputOption('format',null, InputOption::VALUE_REQUIRED,'The output format (txt, xml, json, or md)','txt'), | ||
| newInputOption('show-hidden',null, InputOption::VALUE_NONE,'To show hidden commands'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
No opinion (as we can also use application descriptors in code, so as calling commands).
ogizanagi commentedDec 28, 2016
There is one more thing to consider regarding the I'll wait some more opinions and remove the option if it doesn't seem appropriated. |
ro0NL commentedDec 28, 2016
Not sure, we wanna micro optimize that? The definition is clear, allowing everybody to rely on it consistently. |
| */ | ||
| protectedfunctiondescribeApplication(Application$application,array$options =array()) | ||
| { | ||
| $describedNamespace =isset($options['namespace']) ?$options['namespace'] :null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
The suggestion ofgetApplicationDescription was to move (global) option management to a single place. Keeping this doesnt solve that, gaining only 1 option * 4 descriptors.
Imo. we should rely on some$description->getNamespace() as of below, otherwise maybe revert.
fabpot commentedDec 30, 2016
"Then the initial (by now ;-)) approach makes sense. Including for technical formats, excluding for human formats." -> like that. |
ogizanagi commentedDec 30, 2016
|
| { | ||
| $describedNamespace =isset($options['namespace']) ?$options['namespace'] :null; | ||
| $description =newApplicationDescription($application,$describedNamespace); | ||
| $description =newApplicationDescription($application,$describedNamespace,true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Imo. the descriptor option was nice :) anyway it's internal code.. we're good 👍
fabpot commentedJan 4, 2017
Thank you@ogizanagi. |
…rs (ogizanagi)This PR was merged into the 3.3-dev branch.Discussion----------[Console] Show hidden commands in json & xml descriptors| Q | A| ------------- | ---| Branch? | master| Bug fix? | no (may be considered, but as hidden commands did not exist before 3.2, looks more like a behavior change, hence a feature)| New feature? | yes| BC breaks? | no| Deprecations? | no| Tests pass? | yes| Fixed tickets |#20866 (comment)| License | MIT| Doc PR | N/ACommits-------b6cf240 [Console] Show hidden commands in json & xml descriptors