commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Ferguson" <Andrew.Fergu...@arm.com>
Subject RE: [cli] commons cli version 2.0?
Date Thu, 07 Oct 2004 17:35:14 GMT
> Thanks for that, I've added a new test (based on yours) and fixed
existing ones.  It turns out that GroupImpl was only validating options
that are present and skipping those that were missing.  > I've fixed
this in cvs but no binary is available yet.

ok thanks, I've updated my local checkout now and picked it up. I've
being playing with it some more and have some more minor points..

1) On the Builder classes the reset() method has a void return type

	This means that you can't reuse the same builder within one
large expression for multiple options (eg because the PreferredName is
set to the first value used)?

	eg. Code like this is currently blocked

	DefaultOptionBuilder dob = ...
	Group wizardArgs =
		gBuilder
			.withOption(
			oBuilder
			.reset()
			.withLongName("opt1")
			.withLongName("altopt1")
			.create()
			).withOption(
			oBuilder
			.reset()
			.withLongName("opt1")
			.withLongName("altopt1")
			.create()
			).create();

2) Some error messages could be more specific eg in
DefaultOption.validate

	
===================================================================
	RCS file:
/home/cvspublic/jakarta-commons/cli/src/java/org/apache/commons/cli2/opt
ion/DefaultOption.java,v
	retrieving revision 1.3
	diff -r1.3 DefaultOption.java
	187c187
	<             throw new OptionException(this);
	---
	>             throw new OptionException(this,
"cli.error.missing.required", preferredName);

3) (As noted before) in the "svn/cvs"-style usage there is no easy way
to determine which command has been invoked - a (hacky?) workaround is
to do something like

	String command = null;
	for(Iterator i = line.getOptions().iterator(); i.hasNext(); ) {
		Option o = (Option) i.next();
		if(!o.getPreferredName().startsWith("-")) {
			if(command!=null) {
				throw new RuntimeException("You can only
specify one command"); // this is never thrown as the top-level Group
has a maximum of 1
			} else {
				command = o.getPreferredName();
			}
		}
	}

	I'm not sure what a nice API for this would be though - maybe
something to look at only the top level options passed (and not their
children)

		CommandLine line = ...
		...
		line.getTopLevelOptions(); ??

4) (As noted before) For non-group option implementations nesting
exceptions might be a way of allowing detailed information about where
the parse error occurred
	eg in the validate method in Command you could have

    public void validate(WriteableCommandLine commandLine)
        throws OptionException {
        if (isRequired() && !commandLine.hasOption(this)) {
            throw new OptionException(this);
        }
        try {
                super.validate(commandLine);
        } catch(OptionException oe) {
                OptionException mine = new OptionException(this); // or
maybe the message should be altered to "Command "+preferredName+"
"+oe.getMessage());
                mine.initCause(oe);
                throw mine;
        }
    }

	which would mean the HelpFormatter would need to iterate to the
end of the chain of exceptions to find the true message (or as in the
comment above parent options could prefix additional
	information about what is going on). Its probably better to have
the HelpFormatter construct this detailed message as an option if this
idea has any milage in it

Also, if you do need/want some extra coding/docs time then I might be
able to get permission to allocate some time to lending a hand?

thanks,
Andrew

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


Mime
View raw message