Whoops - hit the message size limit. This time I've chucked the zip file on the web at http://www.oxspring.demon.co.uk/cli/clirob2.zip.
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 Rob ----- Original Message ----- From: "Rob Oxspring" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "John Keyes" <[EMAIL PROTECTED]> 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 class. 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. Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
