commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <>
Subject Fw: [CLI][Proposal] V2 Model
Date Sun, 06 Jul 2003 21:55:58 GMT
Whoops - hit the message size limit.  This time I've chucked the zip file on the web at

I forgot to mention that the new model doesn't have the CommandLine vs CommandLineImpl vs
CommandLineCreator distictions.  There isn't any reason for this and it might be a good idea
to fit this distinction back in.

Also people should check out the Builders, particularly how the ArgumentBuilder fits in with
Parents (I think the ApplicationTest has some real world-ish examples).  I'm not sure how
natural this will feel and am open to ideas on how to do it better


----- Original Message ----- 
From: "Rob Oxspring" <>
To: <>
Cc: "John Keyes" <>
Sent: Sunday, July 06, 2003 10:26 PM
Subject: [CLI][Proposal] V2 Model

Hi all,

After posetive feedback from my previous model suggestion I've been working some more.  The
model still only deals with parsing so far but now copes with option groups, switches, and
anonymous arguments.  I've used the o.a.c.cli2 package now just to keep my changes together
as a unit, a global replace of "cli2" to "cli" is probably needed before committing to any
branch.  Below are the changes of note for this snapshot:

Dropped the word Option from a few classnames as it seemed unnecessary.

Option.getPrefixes() becomes Option.triggers().  This seems to match the usage "the set of
strings that trigger this option" and
allows me to use prefixes to mean something else...

added Option.prefixes().  This returns the set of strings that this Option considers an option
prefix.  DefaultOptions would add "-"
and "--" to the set, commands would add each of their names, and switches would add "+","-"
(or whatever).  Groups would return the
union of their Options' prefixes().  These can then be used when processing argument values
to decide whether a particular arg[n]
looks like an option or not.

Formalised Argument so that it is an interface with two methods processParent(..) and processValues(...).
 This makes it reflect
Parent more closely

Renamed Options to Group.  Makes it easier to spot the distinction between Option and Options
both in code and discussion.  Also I've formalised Group to be an interface with a default
GroupImpl that can be built with a GroupBuilder instance.  I've also removed the Exclusive/InclusiveGroup
classes that existed at one point and added minimum and maximum parameters to the GroupImpl
constructor - this should allow functionality to be implemented more flexibly in a single

Still to do:

Option currently has a commented out validation method.  Some validation method needs to be
added and implemented throughout to properly cope with the complex rules that exist.

Plugin validation.  Something like the current ValueValidator needs to be plugged in somewhere.

HelpFormatter and friends.  I've got plans for how these will work but nothing coded up yet.

Lots of docs and tests.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message