You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rob Oxspring <ro...@imapmail.org> on 2003/10/19 13:19:46 UTC
Re: [CLI] Sandbox Candidate
Joakim,
As I understand things you are talking of something similar to the
reflection builder as John has pointed out. The builder will act as wrapper
around the CLI2 framework, using reflection to build a group of Options and
then making use of the CLI2's parsing and help formatter, before passing the
values back to the bean.
If you fancy trying to adapt your code to work with the CLI2 framework I'm
sure it would be greatly appreciated, although cli2 is a little bit of a
moving target at the moment. I *think* John has ReflectionBuilder code in
the wings ready to adapt to cli2 but comments, ideas and alternative code
are all good. You might want to attach any conclusions / implementations to
the ReflectionBuilder bugzilla entry
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20211.
Thanks,
Rob
----- Original Message -----
From: "Joakim Ohlrogge" <j_...@hotmail.com>
To: <co...@jakarta.apache.org>
Sent: Sunday, October 19, 2003 9:27 AM
Subject: Re: Sandbox Candidate
> Hi John,
>
> Thanks for your reply. I can't believe that I missed CLI when I browsed
> commons!!!
> I have been looking through the sand box code (didn't find the reflection
> builder you talked about though) and here are my two cents:
>
> (but remember that I didn't even see that CLI even existed at first so I
may
> have missed something more :))
>
> Not surprisingly there is a bit of overlap between CLI and what I have
been
> doing but it seems that the points of focus are a bit different. I don't
> know how much the usage scenarios have changed form cli to cli2. Looking
at
> the code there seems to be differences but I'm not sure about the
magnitude
> of the differences.
>
> CLI seems to focus heavily on the parsing part of different types of
> command-lines. It provides great support for different types of syntaxes,
> print usage for those syntaxes etc. My aproach tries to make the parsing
as
> transparent as possible but provides less flexibility when it comes in the
> parsing area.
>
> I think an implementation of the DateApp usage scenario is the best way to
> show the difference.
> Here is how you do it with my experimental framwork:
>
> 1) Create a bean that has properties for the arguments you want
>
> public class DateApp{
> private boolean printTime;
>
> public boolean isPrintTime() {
> return printTime;
> }
>
> public void setPrintTime(boolean printTime) {
> this.printTime = printTime;
> }
> }
>
> Now you can actually get a configured instance of the bean using the
> "getConfiguredInstance(String args[])" method on the BeanConfigurator. You
> can also get a usage print for the bean in this stage.
>
> 2) If you wan't the bean to be executeable, make it implement Executeable
>
> public class DateApp implements Executeable {
> ...
> properties removed for readability
> ...
> public void execute() throws ExecutionError {
>
> Date dt = new Date(System.currentTimeMillis());
> DateFormat df;
> if (isPrintTime())
> {
> df = DateFormat.getDateTimeInstance(DateFormat.SHORT,
> DateFormat.SHORT);
> }
> else
> {
> df = DateFormat.getDateInstance(DateFormat.SHORT);
> }
> System.out.println(df.format(dt));
> }
> }
>
>
> Now we have a bean that can be run using the BeanRunner. The BeanRunner
has
> a main method that looks for the presence of the "bean=my.package.MyBean"
> system property. If the class is found and it implements executeable it is
> configured from the commandline arguments and executed.
>
>
> Building on to the DateApp example we add an optional locale attribute:
>
> public class DateApp implements Executeable{
> private boolean printTime;
> private Locale locale = Locale.getDefault(); // If the locale is null
it
> is considered a required attribute!
>
> public Locale getLocale() {
> return locale;
> }
>
> public void setLocale(Locale locale) {
> this.locale = locale;
> }
>
> public boolean isPrintTime() {
> return printTime;
> }
>
> public void setPrintTime(boolean printTime) {
> this.printTime = printTime;
> }
>
> public void execute() throws ExecutionError {
> Date dt = new Date(System.currentTimeMillis());
> DateFormat df;
> if (isPrintTime())
> {
> df = DateFormat.getDateTimeInstance(DateFormat.SHORT,
> DateFormat.SHORT, locale);
> }
> else
> {
> df = DateFormat.getDateInstance(DateFormat.SHORT, locale);
> }
> System.out.println(df.format(dt));
> }
> }
>
>
> Thats all it takes, now we have an optional locale argument and the print
> usage has been updated for us to look like this (not the prettiest out put
> but this is not the important point):
>
> Usage: [+/-switches] [-options]
> Switches +<switch> turns switch on, -<switch> turns switch off.
> Default setting is indicated between braces.
> +/-printTime[off] printTime
>
> Options, reqired options are marked with a '*':
> -locale <Locale> locale
>
>
> If a DateApp2BeanInfo class would exist in the Introspectors search path
it
> would use the short description from the property descriptors in the print
> usage statement. It would also look for "alias" attributes. What an alias
> attribute does is provide a means for naming your commandline arguments.
> Using this technique we could change "+/-printTime" to "+/-t" if we so
> desire.
>
> What do you think? It attacks the problem slightly differently than CLI.
You
> cant really see any indication that the bean will be used from the command
> line other than the implementation of the "Executable" interface.
>
> Does CLI currently provide anything like this? I believe that CLI could
> strenghten some of the weaknesses in my work. From what I have seen of CLI
I
> think my work could probably fill some purpose not yet covered in CLI.
What
> do you think? Interested?
>
> >From: John Keyes <jb...@mac.com>
> >Reply-To: "Jakarta Commons Developers List"
> ><co...@jakarta.apache.org>
> >To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> >Subject: Re: Sandbox Candidate
> >Date: Sun, 19 Oct 2003 00:08:01 +0100
> >
> >Hi Joakim,
> >
> >There is a command line processing framework called
> >CLI in commons already. A ReflectionBuilder was
> >already submitted for this. It hasn't been added to
> >CLI yet as we are currently developing CLI2. When we
> >have reached a *stable* point we will be refactoring
> >the ReflectionBuilder. If you are interested take
> >a look at the CLI2 code (jakarta-commons-sandbox/cli)
> >and see how this fits with your code. It'll probably
> >be a couple of weeks before we are ready to look at
> >the this.
> >
> >Let us know what you think.
> >
> >Cheers,
> >-John K
> >
> >On Saturday, Oct 18, 2003, at 23:43 Europe/Dublin, Joakim Ohlrogge wrote:
> >
> >>Hi all!
> >>
> >>I don't know the proper procedure for getting a project into the sandbox
> >>area. I have put together a nifty framework that greatly sipmplifies
> >>writing commandline tools that I think would fit nicely into the commons
> >>project.
> >>
> >>I'll describe it shortly here and see what you think.
> >>
> >>When I was refactoring yet another "if else if else" comandline parser I
> >>wondered if there wasn't a more generic approach to the problem. After
> >>some pondering I came up with the folowing solution:
> >>
> >>Writing the command line tool as a bean would make the tools parameter
> >>self describing using introspection. Since introspection supports a
short
> >>description I realized that I could even generate a print usage for the
> >>bean.
> >>
> >>So this is what I have today:
> >>
> >>* a framework to configure a bean from a string array (like the
arguments
> >>passed to the main method for instance)
> >>* a runner that can configure and execute any bean that implements
> >>executeable.
> >>* an automaticly generated print usage that uses introspection to find
> >>descriptions for each parameter
> >>* a way of giving a parameter a shorter name than the property name
( -cp
> >>instead of -classpath for instance)
> >>* treating null values from get methods as required properties
> >>
> >>In the pipe features
> >>
> >>* support "unflagged" parameters like <class> as opposed to -cp <path> a
> >>-cp <path> <class>"
> >>* support for optional extra arguments like <file>[<file>*]
> >>
> >>
> >>So basically any java class conforming to the JavaBeans specification is
> >>configurable.
> >>
> >>If you want to make it runnable the bean has to implement a custom
> >>interface called Executeable. Executeable just adds an execute() method.
> >>(In practice this is the command pattern)
> >>
> >>If you want descriptions of the parameters in your print usage rather
than
> >>just a listing of the parameter names you can use... Just create a
regular
> >>BeanInfo class and make sure it accessible from the introspector.
> >>
> >>It's pretty simple actually :)
> >>
> >>So, are you guys interested and how do I proceed if I want to donate the
> >>code to the commons project?
> >>
> >>/J
> >>
> >>_________________________________________________________________
> >>Hitta rätt köpare på MSN Köp & Sälj http://www.msn.se/koposalj
> >>
> >>
> >>---------------------------------------------------------------------
> >>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
> >
>
> _________________________________________________________________
> Hitta rätt på nätet med MSN Sök http://search.msn.se/
>
>
> ---------------------------------------------------------------------
> 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
Re: [CLI] Sandbox Candidate
Posted by John Keyes <jb...@mac.com>.
> If you fancy trying to adapt your code to work with the CLI2 framework
> I'm sure it would be greatly appreciated, although cli2 is a little
> bit of a moving target at the moment. I *think* John has
> ReflectionBuilder code in
> the wings ready to adapt to cli2 but comments, ideas and alternative
> code are all good. You might want to attach any conclusions /
> implementations to the ReflectionBuilder bugzilla entry
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20211.
The code is also available in this bug report.
-John K
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org