[
https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugi...
]
Brian Stansberry edited comment on WFCORE-2283 at 3/23/17 3:57 PM:
-------------------------------------------------------------------
Some random thoughts...
One is if I'm looking for something and it isn't proposed, I'm going to be
confused and, if it happens a lot, eventually mad. So how to mitigate that?
* If they hit tab twice, show them all?
* If the list is short, show them all? I think this is particularly relevant if the user
has typed something before hitting tab.
* Some kind of text output before the list that indicates the list is filtered?
Another thing is there are other useful relationships besides whether an attribute is
required. For example
A -- required, alternative is B
B -- required, alternative is A
C -- required
D -- not required, requires A
If I added A to the operation, and then hit tab, I'd want to see D even though
it's not required. I configured A which means I've expressed interest in the
"A functionality" and therefore the related D should be shown. (I also
wouldn't want to see B since it is illegal now.)
The downside to all this stuff I mention here is there's no longer any obvious to the
user rule to explain when stuff appears. So it could seem a bit mysterious. Having an easy
way to get an unfiltered list (e.g. second tab) would help mitigate that.
An easy way to get the unfiltered list is also a built-in workaround to the bugs that are
likely to crop up with this.
was (Author: brian.stansberry):
Some random thoughts...
One is if I'm looking for something and it isn't proposed, I'm going to be
confused and, if it happens a lot, eventually mad. So how to mitigate that?
* If they hit tab twice, show them all?
* If the list is short, show them all? I think this is particularly relevant if the user
has typed something before hitting tab.
* Some kind of text output before the list that indicates the list is filtered?
Another thing is there are other useful relationships besides whether an attribute is
required. For example
A -- required, alternate is B
B -- required, alternate is A
C -- required
D -- not required, requires A
If I added A to the operation, and then hit tab, I'd want to see D even though
it's not required. I configured A which means I've expressed interest in the
"A functionality" and therefore the related D should be shown. (I also
wouldn't want to see B since it is illegal now.)
The downside to all this stuff I mention here is there's no longer any obvious to the
user rule to explain when stuff appears. So it could seem a bit mysterious. Having an easy
way to get an unfiltered list (e.g. second tab) would help mitigate that.
An easy way to get the unfiltered list is also a built-in workaround to the bugs that are
likely to crop up with this.
Make 'required' attributes clearer when using tab completion
within CLI
-----------------------------------------------------------------------
Key: WFCORE-2283
URL:
https://issues.jboss.org/browse/WFCORE-2283
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Darran Lofthouse
Assignee: Jean-Francois Denise
The following is some example output pressing tab to reveal the parameters of
'add': -
{{[standalone@localhost:9990 /] ./subsystem=elytron/key-store=localhost:add(
! alias-filter credential-reference path provider-name providers relative-to
required type }}
From this is it not clear which are actually required.
Suggestions to make it clearer: -
* Show required / optional in different colours.
* Add something to the required attributes e.g. '*'
* Add something to the optional requirements e.g. {optional_arg}
Maybe this can go one step further and take into account arguments already added by the
user, especially where attributes require another attribute or are an alternative.
Once an attribute is identified as being an alternative to another attribute maybe it
should be omitted altogether from the list or maybe also have something adding to it
!attr_name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)