[CLI] xml2cli - what's in mind?

[Rob Oxspring <ro...@imapmail.org>]

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

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")){
        ...
    }
    ...
}


2) Generated CommandLine wrapper
+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.  (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.

But the question remains - what do others have in mind?

Rob


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