commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Oxspring <roxspr...@imapmail.org>
Subject Re: [cli] commons cli version 2.0?
Date Fri, 01 Oct 2004 14:06:53 GMT
Comments inline

Andrew Ferguson wrote:
> hi,
>  
> thanks very much for the information :)
> 
----8<----
detail snipped
----8<----
> 	1) There is only one OptionException to cover all problems - is
> the idea to use the Option available to infer any additional detail you
> need?
> 		This seems strange compared to CLI1.0 where there were
> specific exception subclasses?

My early versions of the CLI2 model included several exceptions covering the 
various situations but we merged them all into one feeling that people were 
unlikely to be interested in the differences.  I assume you want to know, for 
a given exception, whether to give tool level help or command level help? I'm 
not sure how best to achieve this off hand and am not even sure that more 
specific exception classes would help.

On another tack, it seems that svn doesn't try to be clever in how it helps 
you out of this situation and simply guides the user a step at a time:

   D:\>svn checkout --user rob
   svn: invalid option: --user
   Type 'svn help' for usage.

   D:\>svn help
   usage: svn <subcommand> [options] [args]
   Type "svn help <subcommand>" for help on a specific subcommand.
(then lists commands and aliases)

   D:\>svn help checkout
   checkout (co): Check out a working copy from a repository.
   usage: checkout URL... [PATH]
(then displays checkout help)

This approach should be easy enough, though not quite as helpful as your aim.

> 
> 	2) When giving a Command a list of Options required parameter is
> not respected?
>              For example - above it seems to make no difference if foo
> or bar are required or not?
>              You can use the Group's setMinimum, setMaximum methods but
> this can't mimic the behaviour needed for the majority of cases

When you say "make no difference" do you mean in the displayed help or in the 
processing?  I'm pretty sure it should validate as you expect: first 
validating each of the options and then validating the number of them against 
the minimum/maximum.  I'll try and have a look over the weekend but if you 
could send me an example (test case would be ideal) that demonstrates the 
problem the it'll be easier to resolve.

> 
> 	3) The default behaviour when displaying the usage of the whole
> command line lists the commands one by one eg
> 
>              Usage:
>                   command1 -f|-b|-h command2 command3 help
> 
> 	which is correct but possibly something people writing tools of
> this form will all need to change.

I'm not really sure what to do about this, I think its safe to say that the 
defaults can never suit every use.  I assume you've  discovered and played 
with DisplaySettings to customise fullUsageSettings in HelpFormatter?  I did 
wonder about automatically switching options to shorter forms until they all 
fit on a single line, which might result closer to what you're after.  That 
would have to wait for a later release though, I think.

Thanks,

Rob

> 
> Anyhow, the overall framework looks great although I've not yet
> understood a number of things I think.
> 
> thanks,
> Andrew

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message