-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[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 our terms of service and privacy 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
Conversation
ogizanagi
commented
Dec 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 |
Nice 👍 what about |
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. |
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 |
Just waiting for some more feedbacks on this and the option suggestion. But ok, done. |
I think I'm 👎 on the |
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 = new ApplicationDescription($application, $namespace); | ||
$namespace = isset($options['namespace']) ? $options['namespace'] : null; | ||
$showHidden = isset($options['show_hidden']) ? $options['show_hidden'] : false; | ||
$description = new ApplicationDescription($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 a ApplicationDescription
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)
@@ -178,6 +178,15 @@ The output format (txt, xml, json, or md) | |||
* Is multiple: no | |||
* Default: `'txt'` | |||
|
|||
#### `--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.
Maybe To 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 :)
*/ | ||
public function __construct(Application $application, $namespace = null) | ||
public function __construct(Application $application, $namespace = null, $showHidden = false) |
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.
@@ -85,6 +86,7 @@ private function createDefinition() | |||
new InputArgument('namespace', InputArgument::OPTIONAL, 'The namespace name'), | |||
new InputOption('raw', null, InputOption::VALUE_NONE, 'To output raw command list'), | |||
new InputOption('format', null, InputOption::VALUE_REQUIRED, 'The output format (txt, xml, json, or md)', 'txt'), | |||
new InputOption('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).
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. |
Not sure, we wanna micro optimize that? The definition is clear, allowing everybody to rely on it consistently. |
@@ -64,7 +64,7 @@ protected function describeCommand(Command $command, array $options = array()) | |||
protected function describeApplication(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 of getApplicationDescription
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.
"Then the initial (by now ;-)) approach makes sense. Including for technical formats, excluding for human formats." -> like that. |
|
@@ -64,7 +64,7 @@ protected function describeCommand(Command $command, array $options = array()) | |||
protected function describeApplication(Application $application, array $options = array()) | |||
{ | |||
$describedNamespace = isset($options['namespace']) ? $options['namespace'] : null; | |||
$description = new ApplicationDescription($application, $describedNamespace); | |||
$description = new ApplicationDescription($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 👍
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/A Commits ------- b6cf240 [Console] Show hidden commands in json & xml descriptors