You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rob Oxspring <ro...@imapmail.org> on 2004/03/27 12:10:36 UTC
[CLI] Application utility class (was Re: [CLI] PatternOptionBuilder)
Moving to the list for wider comment. (will reply separately)
-------- Original Message --------
Subject: Re: [CLI] PatternOptionBuilder
Date: Fri, 26 Mar 2004 17:39:21 -0500 (EST)
From: Michael Heuer <he...@acm.org>
To: Rob Oxspring <ro...@imapmail.org>
On Fri, 26 Mar 2004, Rob Oxspring wrote:
> I'm pretty sure this is doable in cli2, is there any particular part of
> it that's causing you problems?
I guess I'm looking for something like the attached file
Application.java
(although to be honest I don't really like the class name)
I'm a bit confused on the createOptions() method -- do I have this right
by returning a Group containing all the Options? Perhaps you could show
me or point me to an example of what this method's implementation might
look like.
If I wanted the Application class to add "standard" options like --help
and --verbose should I just add those to the Group that is returned?
In my 1.0 version the abstract class held an instance of Options and the
abstract method was
protected abstract addOption(Option);
Thank you for your help.
michael
-------- Original Message --------
Subject: Re: [CLI] PatternOptionBuilder
Date: Fri, 26 Mar 2004 17:53:11 -0500 (EST)
From: Michael Heuer <he...@acm.org>
To: Rob Oxspring <ro...@imapmail.org>
I guess I'd also like it if
parser.parseAndHelp(String[])
did something better than return null if an OptionException is thrown. Or
maybe I should call parser.parse(String[]) and deal with the exceptions
myself?
This illustrates the problem:
$ java -classpath "commons-cli-2.0.jar;." MyTask --not-a-valid-option
Unexpected --not-a-valid-option while processing
Usage:
[]
hello world.
given
MyTask.java
import org.apache.commons.cli2.Group;
import org.apache.commons.cli2.Application;
import org.apache.commons.cli2.builders.GroupBuilder;
public class MyTask
extends Application
{
public MyTask(final String[] args)
{
super(args);
}
protected Group createOptions()
{
return new GroupBuilder().create();
}
public void run()
{
System.out.println("hello world.");
}
public static void main(final String args[])
{
MyTask mt = new MyTask(args);
mt.run();
}
}
Re: [CLI] Application utility class (was Re: [CLI] PatternOptionBuilder)
Posted by Rob Oxspring <ro...@imapmail.org>.
> -------- Original Message --------
> Subject: Re: [CLI] PatternOptionBuilder
> Date: Fri, 26 Mar 2004 17:53:11 -0500 (EST)
> From: Michael Heuer <he...@acm.org>
> To: Rob Oxspring <ro...@imapmail.org>
>
>
> I guess I'd also like it if
>
> parser.parseAndHelp(String[])
>
> did something better than return null if an OptionException is thrown. Or
> maybe I should call parser.parse(String[]) and deal with the exceptions
> myself?
Well my thinking with the method was to make things extremely easy for
simple applications so if it's not making life easier then something
should be done.
The problem with returning null is that the method is trying to convey
one of three states:
1) There was a parsing error, the application should stop (throws
OptionException)
2) Usage informatino displayed, the application should stop (return null)
3) Everything is good, carry on (return CommandLine instance)
Two solutions I can see are:
First is to throw an exception even in case 2.
Second is to move parseAndHelp over to the utility class and have it
call System.exit(). If we go the utility class route I'd be tempted to
move the parseAndHelp method there whichever way we jump.
I guess we should also try and get a broad agreement of what such a
quick-start utility should do and how people would want to use it before
we get too deep into the implementation though.
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] Application utility class (was Re: [CLI] PatternOptionBuilder)
Posted by Rob Oxspring <ro...@imapmail.org>.
Rob Oxspring wrote:
> Moving to the list for wider comment. (will reply separately)
>
> -------- Original Message --------
> Subject: Re: [CLI] PatternOptionBuilder
> Date: Fri, 26 Mar 2004 17:39:21 -0500 (EST)
> From: Michael Heuer <he...@acm.org>
> To: Rob Oxspring <ro...@imapmail.org>
>
>
> On Fri, 26 Mar 2004, Rob Oxspring wrote:
>
>> I'm pretty sure this is doable in cli2, is there any particular part of
>> it that's causing you problems?
>
>
> I guess I'm looking for something like the attached file
>
> Application.java
>
> (although to be honest I don't really like the class name)
Maybe ApplicationHelper? Dunno. I think I get where you're coming from
though; while the api is pretty application agnostic, it would also be
good to help out those that simply want to hit the ground running. It
would be much more prescribing of how people write their application
than the API but it would be totally optional.
>
> I'm a bit confused on the createOptions() method -- do I have this right
> by returning a Group containing all the Options? Perhaps you could show
> me or point me to an example of what this method's implementation might
> look like.
Yeah - I'd have it returning a Group instance. Implementations would
grab a GroupBuilder and pretty much look like the majority of the test
cases in o.a.c.cli2.apps.
>
> If I wanted the Application class to add "standard" options like --help
> and --verbose should I just add those to the Group that is returned?
Absolutely.
>
> In my 1.0 version the abstract class held an instance of Options and the
> abstract method was
>
> protected abstract addOption(Option);
This could still be done instead of the createOptions() method. It
would simply mean that the Application class is responsible for creating
the Group rather than the option.
>
> Thank you for your help.
>
> michael
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org