I'd envisaged the conversion String->Integer to be handled by some IntegerValidator
class attached to the Argument. If this pattern
is chosen then I'm not sure how practical overloaded methods would be - the range of
types that could be returned would be infinite
and we'd have to think about where to draw the line before the number of convenience
methods grows too big. I guess the sensible
place to draw that line would be for the Java primitives as anything else can easily
be cast from an Object anyway.
Of course this is ignoring the fact that an XML configuration would have the full
knowledge of which types were needed where. To be
honest though I really need to think about the xml2cli thing. I like the idea in
principle but I'm really struggling to get a
handle on what input would be supplied, what might be generated and how the client
code would interact with cli to respond to the
chosen options. The end points are still to blurry in my head to see what
transformation is needed. But I'll switch the xml stuff
to a new thread.
Rob
----- Original Message -----
From: "Henri Yandell" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, August 12, 2003 3:26 AM
Subject: RE: [CLI] 2.0 Proposal
>
> I solve this in my configuration classes via overloaded methods.
>
> conf.getValue(); Object
> conf.getString(); String
> conf.getInteger(); Integer
>
> etc.
>
> On Mon, 11 Aug 2003, Gary Gregory wrote:
>
> > - XML configuration?
> >
> > It just dawned on me that starting from an XML file would not only allow for
> > a tool to generate cli2 "builder" code, but that additional type-safe
> > wrapper methods could be generated such that instead of an app doing:
> >
> > String name = cmd.getValue("n");
> > int count = Integer.parseInt(cmd.getValue("c"));
> >
> > You could have:
> >
> > String countryCode = myCmd.getName();
> > int count = myCmd.getCount();
> >
> > Which is stuff I end up doing in my apps now.
> >
> > Gary
> >
> > -----Original Message-----
> > From: Rob Oxspring [mailto:[EMAIL PROTECTED]
> > Sent: Monday, August 11, 2003 17:10
> > To: Jakarta Commons Developers List
> > Subject: [CLI] 2.0 Proposal
> >
> > Hi all,
> >
> > I've finally got to another sensible point to present my CLI2 proposal.
> > I've started using the maven build process so this time I'm able to supply
> > binaries as well as sources, unfortunately though, I've not bothered to get
> > them named sensibly yet.
> >
> > Grab zips from http://www.oxspring.demon.co.uk/cli/3/ and have a quick look
> > at http://www.oxspring.demon.co.uk/cli/3/docs/usage.html for a first cut of
> > basic usage documentation.
> >
> > So, features:
> >
> > - Complete rewrite to use clean model from the beginning.
> > - Sits in org.apache.commons.cli2 so that there is no conflict with the
> > cli1 class files - they can probably be deprecated rather than deleted.
> > - Each Option implementation is responsible for its own functionality -
> > parsing, validation, help/usage strings all handled by the Options
> > themselves.
> > - Copes with standard options, cvs style commands and +/- switches with
> > arguments and in flexible groups.
> > - Copes with java style property arguments and "--" options in a clean
> > mannar
> > - Anonymous arguments "fall out" of the design (just add to a Group)
> > - Easily extended to new option types with minimal changes necessary
> > - HelpFormatter has returned
> > - CommandLineParser adds parseAndHelp(..) method to easily add basic
> > error reporting and usage help to client applications (Only thought of this
> > at the weekend but it seems to work and only throws the IOException of
> > writing out the help
> > http://www.oxspring.demon.co.uk/cli/3/docs/usage.html#Querying%20CommandLine
> > )
> > - Order of Options is dependant on Comparators so can be customised at
> > runtime.
> >
> >
> > And still todo:
> > - More docs
> > - Pluggable argument validation
> > - XML configuration?
> > - Reflection configuration?
> > - Ant task generation?
> > - Always more tests
> >
> >
> > Any thoughts and comments are welcome,
> >
> > Rob
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
