commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [CLI] Feature requests and submissions
Date Thu, 01 Aug 2002 12:57:32 GMT
> From: John Keyes [mailto:jbjk@mac.com] 
> 
> Hi Berin,
> 
> I have added an iterator method to CommandLine (not yet
> commited) which returns a java.util.Iterator of the Option keys.
> 
> An example of using this would be as follows:
> 
> // create options object
> Options options = ...;
> 
> CommandLineParser parser = CommandLineParserFactory.newParser();
> CommandLine line = parser.parse( options, args );
> 
> Iterator iter = line.iterator();
> while( iter.hasNext() ) {
>     String opt = iter.next().toString();
>     String value = line.getOptionValue( opt );
>     String value = line.getOptionValue( opt, "default value" );
>     String[] values = line.getOptionValues( opt );
>     Object obj = line.getOptionObject( opt );
> }
> 
> Is this the solution you require?


What I want is a replacement for this type of construct:

CommandLineParser parser =
CommandLineParserFactory.newParser("org.apache.commons.cli.GnuParser");
CommandLine line = parser.parse( options, args );

Iterator iter = line.iterator();

while( iter.hasNext() )
{
    CLIOption opt = (CLIOption) iter.next();

    switch( opt.getShortName() )
    {
        case 'l':
             m_context.put( "log.uri", opt.getValue() );
             break;
        // ....
    }
}

The distinction is that I want a set of CLIOptions (that came from
the commandline parser).  From there I can do a simple switch based
on the option's short name ('int' representation).  Also, it makes
sense to directly retrieve the value from the CLIOption object itself.


The key distinction between the way Commons CLI and Avalon's CLI works
is they way we set up and process options.  Because Avalon is usually
used in servers or for processing engines that might have a lot of
options, we have a different set of needs.

Avalon sets things up in this manner:


// m_options is an array of the type OptionDescriptor[]
Parser parser = new Parser( m_options );

That means we set up our parser with an array of OptionDescriptors.
The descriptors have the important info to help parsing the CLI.
They are essentially the same as your Option objects.

We get the options that are parsed in this manner:

Option[] options = parser.parse( args );

>From there the Option object (which I don't know if you have an equiv.
or not) has all the runtime information necessary.  I.e. it has the
short name, the long name, and any associated values (up to two are
allowed for x=y constructs).  It passes back an array because the same
option may be included multiple times like the Java -D option:

myprog -Dhis.name=JohnJacobJingleHeimerSchmidt -Dmy.name=his.name

Each one of those has to be processed separately.

It can also be used for verbosity levels.  Some programs have up to
three verbosity levels, each one activated with an extra -v option.

myprog -v -v -v
  (or)
myprog -vvv

Both of those are equiv. in GNU standards.

That is the functionality I need.  Although what you did was a step
in the right direction.


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message