commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Herve Quiroz <herve.qui...@esil.univ-mrs.fr>
Subject Re: [CLI] Switches ?
Date Thu, 03 Jul 2003 13:32:15 GMT
Hi Rob,


Wow, I'm impressed! Never thought you could handle it so easily... For me
that means one thing: the new API is efficient, simple AND flexible.

Too bad I am coding XSLT full-time for now because I would really love to
test it and port my apps to the new API. Anyway, I'll try and stay aware
of the changes by reading the list. Expect my further comments (and
possibly contribution) in a few weeks when I'm done with XSLT...

Regards,

Herve

On Wed, 2 Jul 2003, Rob Oxspring wrote:

> Hi Herve,
>
> Cheers for the pointer, I'd forgotten about switches.
>
> I figured I'd use this opportunity to plug my own CLI2 proposal a little more so here's
how I see switches slotting in:
>
> A SwitchBuilder would be created to deal with a specific pair of enable / disable prefixes:
>     SwitchBuilder sBuilder = new SwitchBuilder("+","-");
>
> Then a SwitchOption would be created with a particular name:
>     SwitchOption scrollbar = sBuilder.withName("sb").create();
>
> The getPrefixes() for SwitchOption would return [+sb,-sb] and the CommandLine object
would probably gain a method along the
> following lines; returning TRUE iff the enabled version was present, FALSE iff the disabled
version was present or null otherwise:
>     Boolean getSwitch(SwitchOption)
> (And an associated setSwitch(SwitchOption,Boolean) method)
>
> Separating the prefixes allows us to use the same code to handle ./configure style options
such as "--enable-FEATURE" and
> "--disable-FEATURE" simply by supplying "--enable" and "--disable" instead of "+" and
"-".
>
> If we make the SwitchOption extend ParentOption then we can even compose one with an
Argument as follows:
>
>     // build the switch
>     SwitchOption sslSwitch = new SwitchBuilder("--with-","--without-").withName("ssl").create();
>
>     // wrap in an argument
>     Argument sslArgument = new ArgumentBuilder().withName("DIR").withChild(sslSwitch).create();
>
>     ...
>
>     // deal with ssl
>     if(commandLine.getOption("--with-ssl")==Boolean.TRUE){
>         sslDir = findSsl(commandLine.getValues("--with-ssl"));
>     }
>
> Thus the complex ./configure style options such as "--with-ssl=/usr/share/ssl" / "--without-ssl"
would be supported out of the box.
> The implementation should be pretty straight forward - new classes SwitchOption &
SwitchBuilder, some addition to CommandLine and
> lots of tests.  IMO, minimal impact for a handy new feature.
>
> Rob
>
> ----- Original Message -----
> From: "Herve Quiroz" <herve.quiroz@esil.univ-mrs.fr>
> To: <commons-dev@jakarta.apache.org>
> Sent: Tuesday, July 01, 2003 3:19 PM
> Subject: [CLI] Switches ?
>
>
> > Hi,
> >
> >
> > As you are still in design stage for CLI 2.0, I thought I might just
> > submit another feature that is used by command line parsers for some apps:
> > switches.
> >
> > In CLI, the PREFIX for a command-line option is '-' but may be overriden
> > to become anything else.  Some apps have several different prefixes to
> > manage switches. When you consider xterm for example, you get two flavors
> > for the same option, one that "enable" it (with -option) and one that
> > "disable" it (with +option). For instance,
> >
> >  '-sb' means you want the scrollbar
> >  '+sb' means you don't want it
> >
> > Personally, I wouldn't use such a scheme to parse command line arguments
> > so I won't need it in a future version of CLI (BTW I find the next version
> > quite interesting). Thus, I am not requesting a new feature from CLI here.
> > Anyway, you might want to decide now if you plan to support such a feature
> > in the near future now that you are defining the API...
> >
> > Regards,
> >
> > Herve
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

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


Mime
View raw message