Interesting topic.
Here's another possibility - perhaps an addition to Kedar's suggestion
rather than a replacement.
How about using a completion technique the way that some/many command
line shells do for file specs?
For example:
$asadmin <enter>
$asadmin> deploy <tab>
would display the first option to "deploy" that the user had not yet
used on the command line, perhaps presented in order of
most-frequently-used. So successive <tab> presses at that point might
display --path, then --contextroot, then --name, and so on. Depending
on how clever we want to get, as the user is entering the path value the
<tab> key could do file path matching the way it does in shells!
Taken a step further, if there is a fixed list of values for a given
option (for instance, --virtualserver) asadmin could have retrieved
those values from the DAS and it could display them as the choices for
the option's values.
Personally, I prefer a U/I that guides me to correct input rather than
noting my errors - however politely it may do so - and offering me its
guesses as to what I might have intended. Especially in command-line
U/Is that is not always possible and so the "did you mean?" approach
gives valuable hints when there is no effective way of constraining or
guiding the user in the first place.
- Tim
Kedar Mhaswade wrote:
> I see the essence of what you propose. A bit of "interactivity" when
> software knows it's talking to a human, is probably desirable (if the
> software
> does not overdo it).
>
> Technically, it is generally possible to find out if an asadmin command
> is being run as a part of script or not. A given command can behave
> differently
> based on it.
>
> Two possibilities emerge:
> - Stick to rather "strict" interface when command executes as part of
> script.
> - Be creative and interactive when a human executes commands.
>
> But that gives rise to two flavors of each command and is rather
> expensive.
>
> Can a reasonable compromise be made if we make a simplifying
> assumption that
> "multi-mode" execution of asadmin defaults to interactive use and
> "single-mode"
> execution follows strict interface?
>
> e.g.:
> $asadmin (Enter)
>
> $asadmin> Enter a command or "quit": deploy
> $asadmin> Enter the path of deployable: foo.war
> $asadmin> Enter the context-root[foo]: bar
> ...
> Command "deploy" executed successfully and exited with code 0.
> $asadmin> Enter a command or "quit": create-jdbc-connection-pool
> $asadmin> Enter the name in the naming service (JNDI): jdbc/orapool
> ...
> $>asadmin>Enter a command or "quit": Quit
>
> The syntax for single-command is like-wise, but follows syntax and
> accepts correctly spelled options case-insensitively.
>
> I always believed (as a user) that entering into multi-mode was akin
> to declaring my consent for interaction (aka liveliness).
>
> Thoughts?
>
> - Kedar
>
>
>
> Vince Kraemer wrote:
>> This is starting to sound like the discussion that we had some time
>> back about something similar to the 'Did you mean: x y z?" feature
>> that Google has...
>>
>> See
>> https://glassfish.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=1660.
>>
>> This lead to the great work that Jane did with CLI back in V2:
>> http://blogs.sun.com/janeyoung/entry/finding_cli_commands_in_glassfish
>>
>> Now it is time to take the next step... What is an example of the
>> next step... See http://userscripts.org/scripts/show/9514
>>
>> vbk
>>
>> Other notes in-line...
>>
>> Kedar Mhaswade wrote:
>>>
>>>
>>> Jerome Dochez wrote:
>>>> I was talking to Jane about this yesterday, We need to ensure we
>>>> are satisfying the CLIP requirements but that's definitely my
>>>> feeling too,
>>>>
>>>> just like if someone types --contxetroot, we should interpret it as
>>>> --contextroot...
>>>
>>>
>>> Hmm. That's interesting but difficult to get right and has implications
>>> on "interface" definition and compatibility.
>>> Maybe someone did want to get an error back
>>> on typo? (Otherwise we might have to support all the typos forever!)
>>
>> we might not support typos in scripts... but we want to try to make
>> it easy for the user to keep working....
>>
>> Our CLI is currently like Google search, but we force the user to
>> retype the query... instead of click the "did you mean" link....
>>
>> let's extend the example from jane's blog entry...
>>
>> USER> asadmin create-domian --adminport 4848 --user admin foo
>>
>> current return text>* **Closest matched command(s):
>> create-domain*
>> Use "help" command for a list of valid commands.
>>
>> proposed return text> *Closest matched command(s):
>> create-domain*
>> Use "help" command for a list of valid commands.
>> Execute "asadmin create-domain --adminport 4848 --user admin
>> foo"?
>>
>>
>> If the user enters y/yes/true... the proposed command would be executed.
>>
>> In cases where there are multiple choices of the most likely correct
>> choice, the Execute part of the return text would not appear.
>>
>> I realize that this isn't "clean" from a defined interface
>> perspective... but, humans aren't "clean" from a defined interface
>> perspective, either.
>>
>> This is the kind of feature that can delight a user when they
>> discover it...
>>
>>>
>>> Case-sensitivity is slightly different. For a long option, a "correct"
>>> spelling in any case could be accepted as valid without huge (as in
>>> difficult to deal with) implications.
>>>
>>> Incidentally, I think we need to consider the exit codes from CLI with
>>> some seriousness. I have started a discussion topic at:
>>> http://wiki.glassfish.java.net/Wiki.jsp?page=ProsAndConsOfAsadminExitCodes
>>>
>>> and will be adding content to it soon. A reasonable exit code (and
>>> message)
>>> would indicate the typo like: "Did you mean --contextroot instead"?
>>> would
>>> lead to better overall user experience.
>>
>> I agree. But we can go even higher then that...
>>>
>>> Regards,
>>> Kedar
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>