commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joakim Ohlrogge" <j_ohlro...@hotmail.com>
Subject Re: Sandbox Candidate
Date Sun, 19 Oct 2003 08:27:57 GMT
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 <jbjk@mac.com>
>Reply-To: "Jakarta Commons Developers List" 
><commons-dev@jakarta.apache.org>
>To: Jakarta Commons Developers List <commons-dev@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


Mime
View raw message