Thanks for your reply. I can't believe that I missed CLI when I browsed commons!!!
There's a lot of stuff there, I can understand how you would miss it :-)
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:
That's what I mentioned in my previous mail. It will be at least a couple of weeks before we get around to it. Here is the original submission:
http://marc.theaimsgroup.com/?l=jakarta-commons- dev&m=104288286123791&w=2
The major difference being the *Executable* part.
We'd be glad to hear your contributions though.
Thanks, -John K
(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 <[EMAIL PROTECTED]>
Reply-To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________ Hitta r�tt p� n�tet med MSN S�k http://search.msn.se/
--------------------------------------------------------------------- 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]
