commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject [cli][configuration][convert] Architecting our overlaps
Date Sun, 10 Sep 2006 07:37:39 GMT
So I'm using [cli] in [finder] to see if I can mimic the command line
interface for the unix find command. I'm using the cli2 version - lots
of thought, but very painful to use. Here are the 30 lines of code to
add a single option:

<code>
    public static void main(String[] args) throws OptionException {
        DefaultOptionBuilder obuilder = new DefaultOptionBuilder();
        ArgumentBuilder abuilder = new ArgumentBuilder();
        GroupBuilder gbuilder = new GroupBuilder();

        Option type =
            obuilder
                .withShortName("type")
                .withDescription("True if the file is of the specified type.")
                .withArgument(
                    abuilder
                        .withName("type-flag")
                        .withMinimum(1)
                        .withMaximum(1)
                        .create()
                )
                .create();

        Group options =
            gbuilder
                .withName("options")
                .withOption(type)
                .create();

        Parser parser = new Parser();
        parser.setGroup(options);
        CommandLine cl = parser.parse(args);

        if(cl.hasOption(type)) {
            System.out.println("USE TYPE: " + cl.getValue(type));
        }
    }
</code>

Obviously a second flag wouldn't double it or anything, but it's still
a lot. So my first thought is wondering how the API can be simpler for
simple cases. Power is good, power when it's not needed is
unmanageable.

Perusing the CLI2 javadoc, my second thought is that it overlaps with
Configuration a lot. You can have Properties and Preferences command
lines; and Configuration lacks a CLI style way to input data.

A third thought is that the CLI2 CommandLine API for the data itself
rests on a getValue(Option);Object method, which implies some
conversion is going on but I've not seen how yet by looking at the
API. Configuration also does conversion of String to various objects.
BeanUtils does that too, which gave rise to an overmodelled [convert]
package that we've talked about restarting as something simpler.

--

Any of that kick off any thoughts?

Hen

---------------------------------------------------------------------
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