Below...
> -----Original Message-----
> From: Rob Oxspring [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 12, 2003 03:29
> To: Jakarta Commons Developers List
> Subject: [CLI] xml2cli - what's in mind?
>
> Having discussed building a cli from xml before I've been a little unclear
> about what sort of thing people are suggesting. So here
> i've mapped out three ideas of how it could work to see how they compare
> with what others are thinking. Note that suggestions 2 & 3
> both ignore groups of options as I haven't figured out how to handle
> nesting yet.
>
>
> 1) Runtime configuration.
> +No need to generate code
> +Using Builder classes is wrapped up and tucked away
> -Need xml parser at runtime
> -Querying the CommandLine is still manual
- You need to have the XML config file laying around at runtime. You could
package it in your app's Jar. The XML cannot be tweaked without more than
likely blowing up the app. This is fine, I just want to note that this is
brittle.
>
> a) Xml representation:
> <cli>
> <option name="--help"/>
> <option name="-log">
> <argument name="file" type="java.io.File"/>
> </option>
> <group maximum="1" description="output quality">
> <option name="-s" description="silent"/>
> <option name="-q" description="quiet"/>
> <option name="-v" description="verbose"/>
> <option name="-d" description="debug"/>
> </group>
> </cli>
>
> b) Client code
> public static void main(String args[]){
> Group options = XmlConfig.load("myapp.cli");
> CommandLine cl = new CommandLineParser().parse(args);
>
> if(cl.hasOption("--help")){
> ...
> }
> ...
> }
I would like instead (in my dreams):
public static void main(String args[]){
MyCommandLine myCli = new MyCommandLine(args);
if(myCli.hasHelp()){
...
}
...
}
>
>
> 2) Generated CommandLine wrapper
Ah, you got there! ;-) I was to quick to trigger what I am looking for.
> +No runtime parsing
> +Simplified type safe CommandLine querying
> -Manual querying of CommandLine (wrapper)
>
> a) Xml representation
> <cli classname="MyAppCommandLine">
> <option name="--help"/>
> <option name="-log">
> <argument name="file" type="java.io.File"/>
> </option>
> </cli>
>
> b) Generated code
> public class MyAppCommandLine {
> public boolean isHelpSet(){...}
> public java.io.File getLogFile();
> ...
> }
>
> c) Client code
> public static void main(String args[]){
> MyAppCommandLine cl = new MyAppCommandLine(args);
> if(cl.isHelpSet()){
> ...
> }
> ...
> }
>
>
> 3) JavaBean connection
> +could build a cli for any bean
> +client doesn't need to write a main(String[]) method
> +all CommandLine querying is internal
> +client doesn't need to know about cli classes
>
> a) Xml
> <cli beanname="MyApp">
> <option name="--help" method="doHelp()"/>
> <option name="-log" method="setLogFile(File)">
> <argument name="file" type="java.io.File"/>
> </option>
> </cli>
>
> b) Generated code
> pubilc class MyAppMain {
> public Option help = ...
> public Option log = ...
> public static void main(String[] args){
> MyApp myApp = new MyApp();
> Group options = buildOptions();//boring option building ommitted
> for now.
> CommandLine cl = new CommandLineParser().parse(args);
> if(cl.hasOption(help)){
> myApp.doHelp();
> }
> if(cl.hasOption(log)){
> myApp.setLogFile((File)cl.getValue(log)));
> }
> ...
> }
> }
>
> c) Client code
> public class MyApp {
> public void doHelp(){
> ...
> }
>
> public void setLogFile(File file){
> ...
> }
> }
>
>
> I *think* that what Gary has been meaning is something close to (2) but
> personally I'm not sure the gains over (1) are worth the
> effort.
The gains are pretty clear to me. ;-)
I do not want *my* code to have Integer.parserInt() for every int I really
want if it can be tucked away in CLI. I can factor the conversion code in my
own wrapper of course, but I would consider that a sign of a shortcoming in
CLI: a wrapper on top of the CL wrapper.
As CLI becomes more and more fancy, it could let me specify min, max, etc.
This would all be tucked away in CLI.
To summarize, my app does not want a String representation of an integer and
a Date, it wants the int and the Date object.
(3) on the other hand would be pretty sweet as cli then acts as a
> wrapper to any given bean and there should be room for
> code sharing with a Reflection based configuration too. The 3 methods are
> just points on a scale that seemed to make sense - there
> must be other variations too - but one nice thing is that none of them
> preclude either of the others: if all are liked then all can
> be implemented as needed.
The (3) feels like an event driven wrapper on top of (1) and/or (2). I would
not want to be forced into that. I've always thought of a command line as a
piece of data I pull data out of, not an app driver. But I could imagine a
CLI as app driver from /some/ app.
Thanks for some great ideas.
Gary
>
> But the question remains - what do others have in mind?
>
> Rob
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
