commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Keyes <j...@mac.com>
Subject Re: [cli] Suggestions
Date Fri, 15 Nov 2002 14:25:23 GMT
<snip/>

> This is possible in CLI, e.g. OptionBuilder.withLongOpt( "username"  
> > ).hasArg().create().
> 
> It seems quite awkward (IMHO) to chain together all of those method  
> calls. I got round this with method overloading.
> 
> I have a *lot* of constructors/factory methods in my lib, but there is  
> a simple set of rules that lets you determine what to write, so that  
> constructors work in a very concise, DWIM (do what I mean) fashion.

CLI had this type of feature previously but it was decided that
the Builder was a more flexible and easier to use solution.  
Now, if a new property is being added to Option all that is 
required is the accessor on Option and the property method
on OptionBuilder.

The most basic ctors and factory methods (see Option.addOption) are
in place but to use any *advanced* features the Builder must be used.
This also makes it easier for the user to understand rather than 
having to look up the Javadoc for each ctor.  So I am -1 on 
reintroducing all of the ctors.

<snip/>

> >> 3. Sets of options can be read from and written to properties files.
> >
> > No support for this.  I have a TODO for myself (I must document it) to
> > have an XML reader and writer for configuring an Options instance.  I
> > will document this TODO and also add yours.  If you feel like having a
> > bash at the properties one that would be cool ;)
> 
> Maybe early next week. I should be able to port mine across pretty  
> easily.

Cool.

>> 4. A set of default options is provided (disabled by default) that  
> >> will read properties files during parsing, and write them once  
> >> parsing is completed.
> >>
> >> For example:
> >>
> >> mycommand --properies-file in.properties --some-other-argument  
> >> some_value --write-properties-file out.properties
> >>
> >> reads option values from in.properties, over-rides the value for  
> >> --some-other-argument, and dumps the properties out to >> out.properties.
> >>
> >> The "special" property options names and flags can be fully  
> >> customised via method calls.
> >
> > Might be that I'm a bit sleepy but I don't see what this achieves.   
> > Can you
> > enlighten me please.
> 
> sure.
> 
> imagine my code looks like
> 
> options = myCreateOptions();
> options.setUsePropertiesOptions(true);
> options.parseCommandLine("mycommand", args);
> interrogateOptions(options);
> 
> Calling setUsePropertiesOptions with a true argument means that in  
> addition to the options that I defined, my commandline parsing will  
> also support a predefined set of options relating to properties, which  
> support reading option values in from a properties file, and writing  
> options out to a properties file, and specifying a prefix to add  
> to/subtract from property names.
> 
> This can be very useful if you have a *lot* of command-line options. I  
> have some simulation apps that run like this. Of course one could argue  
> that if you have so many options, you should be using a properties file  
> or some other mechanism anyway, but this approach lets you have the  
> best of both worlds ... specification of options in a properties file,  
> over-rideable from the command line.
> 
> so, for example
> 
> runApp --write-properties-file propertiesfile
> 
> dumps out all of the options, and their default values into a  
> properties file.
> 
> I can now go in and edit this to set a particular set of properties  
> that I want to run
> 
> Now I can rerun the program using my edited properties file to  
> configure the application:
> 
> runApp --properties-file propertiesfile
> 
> Now, if I want to use this properties file as a base, but to override  
> some of the values, I can run
> 
> runApp --properties-file propertiesfile --some-other-option newvalue
> 
> Of course, you may not like those particular option names, so my class  
> provides methods to let you set the name and flags that will be used  
> for each of these options. Of course, the programmer could implement  
> this themselves, on top of CLI, but this way they get it for free (if  
> they choose to turn it on).
> 
> Does that make more sense?

Yeah, thats a good idea.  It would make sense for testing a 
command line.  Can you give me an example of what one of these
properties files would look like.

<snip/>

Thanks,
-John K


--
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