hi,
 
thanks very much for the information :)

I've downloaded the sources and have been playing with the CLI2 api -
specifically the commands section, and have some (possibly confused)
feedback..

I'm interested in developing a tool which has a command line like

        tool <tool options> command <command options> 

and which would have use cases like

1     >>> tool
      Type 'tool help' for usage

2     >>> tool help
      usage: tool <tool options> <subcommand>

      <command> is one of
            a descr-a
            b descr-b
            c descr-c
            d descr-d

3     >>> tool a
      usage: tool <tool options> a <a options>

      <a options>
            -f, --foo
            -b, --bar

and so on (if you have used subversion then pretty much identical to
that).

The model I've tried to use for this is:

     Group (commands) (Minimum=Maximum=1)
            |
            |__ Command (command1)
            |     |
            |     |__ Group
            |           |
            |           |__ Option (f, foo) 
            |           |
            |           |__ Option (b, bar)                     
            |           |
            |           |__ Option (h, help)    <-- command help
            |
            |__ Command (command2)               
            |
            |__ Command (command3)
            |
            |__ Command (help) <-- overall help

but have found the following questions/potential issues

        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?

        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

        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.

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

thanks,
Andrew

-----Original Message-----
From: Rob Oxspring [mailto:[EMAIL PROTECTED] 
Sent: 24 September 2004 12:15
To: Andrew Ferguson; Jakarta Commons Users List
Subject: Re: [cli] commons cli version 2.0?

Hi,

(cc to commons-user since this may be useful to others)

CLI2 is about ready, just waiting for one last bugfix (ready to commit)
and a little documentation.  Unfortunately I'm snowed under with the day
job at the moment so am not sure when I'll get it finshed.  I guess the
new feature list goes something like:
   * switches (+d|-d)
   * commands (a la "cvs update")
   * options without short forms
   * multiple aliases per option
   * optional -D processing (java properties)
   * optional -- processing (consume remaining arguments)
   * fine grained control over what's displayed
   * accepts defaults from Properties
   * accepts defaults from Preferences
   * flexible api

Hiding options from the help formatted isn't supported out of the box
but the api should allow you to acheive that result by wrapping either
the hidden options themselves or the top level Group; the important
thing is to filter the results of helpLines() to exclude the hidden
options.  I'll concentrate on the latter approach and assume all other
methods are delegated directly to the wrapped group: (untested code,
expect typos)

HiddenOptionsGroup implements Group {
     private Set hiddenOptions = new HashSet();
     public void hideOption(Option hidden){
         hiddenOptions.add(hidden);
     }
     public List helpLines(){
         List lines = wrapped.helpLines();
         for(Iterator i=lines.iterator();i.hasNext();){
             HelpLine line = (HelpLine)i.next();
             if(hiddenOptions.contains(line.getOption())){
                 i.remove();
             }
         }
         return lines;
     }
     // delegate remaining methods
}

// then use it as follows
Option secret = ...
Group options = ...
HiddenOptionsGroup hog = new HiddenOptionsGroup(options);
hog.hideOption(secret)
HelpFormatter help = new HelpFormatter(); help.setOptions(hog);
help.printHelp();

Built in support for hidden options may appear in later versions if
there is demand for it.

Hope that helps,

Rob



Andrew Ferguson wrote:
> hi,
>  
>  i was just wondering if you have any details about when CLI2.0 might 
> be available? (and what new features would be available)
>  
> I'm currently using CLI1.0 but am under pressure from other team 
> members because it doesn't support options like
>         1) hidden options that aren't displayed by the help formatter
>         2) options without short forms
>  
> I've had a look around for alternative in the mean time, and am hoping

> not to have to use the java port of getopts since this means back to 
> using switch blocks for processing which is not convenient for the 
> project i'm working on..
>  
> any help appreciated :)
>  
> thanks,
> Andrew
>  



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to