Interesting mail. This sounds good. It would provide a lot of
flexibility alright. I'll try to familarize myself with commons-sandbox-functor
so I can understand the concepts some more but it seems to be a
nice fit.
If we are going to start work on this I will need to the get the code I have written checked in. I wonder should I create a branch for it CLI_2_0_BRANCH and see what happens. Does the decision to create a branch need a vote?
-John K
On Monday, Mar 10, 2003, at 14:31 Europe/Dublin, Herve Quiroz wrote:
Hi,
I've thought of the whole stuff this week-end and IMHO, it would be nice
to use functor for this purpose. Indeed by using unary predicates,
functions and procedures, it would be quite easy to specify the behaviour
we discussed lately.
For example, in OptionBuilder:
* withPostProcess(UnaryFunction f)
When calling line.optionValue(String s), return
f.evaluate(line.optionValue s) instead. May be used to convert the
argument value to numeric value and directly return an Integer instance...
* withPostProcess(UnaryProcedure p)
Upon parsing, if the whole parsing process succeeds, and before returning
the resulting command line, the parser will apply for each option the
post-processing procedures that have been specified. Thus it would allow
to automatically set a system property when a given option is set.
* withPredicate(UnaryPredicate p)
While parsing, for each of the options where one or more predicate has
been associated, the predicates are tested for each value and a false
return condition would have the parser throwing a ParseException embedding
the predicate name. Useful to have the parser automatically perform type
checking, or to test if the specified filename represents an existing
file.
* withPostPredicate(UnaryPredicate p)
Upon parsing, if the whole parsing process succeeds, and before evaluating
post-processing procedures, test the post-processing predicates associated
with each option. Thus it would allow to specify the following behaviour
we discussed: "the --overwrite option is only relevant if an output file
is specified with --output".
Then we could have commonly used predicates, functions and procedures already implemented in the CLI package. For example:
IsExistingFilePredicate() IsReadableFilePredicate() IsWritableFilePredicate() IsIntegerPredicate()
NeedsOptionSetPostPredicate(Option o);
MapToSystemPropertiesProcedure() MapToSystemPropertiesProcedure(String prefix)
GetValueAsIntegerFunction()
Regarding the functor dependency, it could be easy to have the relevant
methods throw an OperationNotSupportedException (which is a
RuntimeException and thus does not need to be catched) when the functor
package is not present in the classpath. This way, functor becomes
mandatory only when building CLI (and obvioulsy when the application that
makes use of CLI needs the features I described in this mail).
What do you think of it ?
Herve
On Thu, 6 Mar 2003, Herve Quiroz wrote:
On Thu, 6 Mar 2003, John Keyes wrote:
Now speaking of something not closely related, I remember reading on thisThis isn't really an OptionGroup issue. Its more general. It should
list something about OptionGroup that would allow rules like "the
--overwrite option is only relevant if an output file is specified with
--output". Is this planned (or already done) for CLI-2 ? Because it could
possibly get easy with the functor/predicate stuff we discussed.
be possible using child options. So --output would have child options,
and when the --output has been handled parse the remaining tokens
using its child options. CLI-2 doesn't exist yet and may not depending
on whether it is voted in. At the moment its an experiment that aims to
improve on the work done for 1.0. So all of this feedback is great as
it shows that people had problems with 1.0 and would like to see them
resolved.
Therefore here is another interesting feature:
I used to use a Configuration object (from jakarta-commons-configuration)
to centralize all preferences in my projects. Hence a lot of command line
options need to be propagated to this configuration instance.
// Initialize configuration with some default values... // Then parse the command line.
if (commnadLine.hasOption("verbose") configuration.setProperty("domain.myapp.verbose","true");
if (commandLine.hasOption("port")
configuration.setProperty("...port",commandLine.optionValue("port"));
It would be nice to specify such a behaviour within the option builder.
And using the functor stuff we discussed, that could stay quite simple.
For example:
OptionBuilder.withPostProcess(new ConfigurationMapperFunctor(config))...
...withLongName("argname").create();
I don't know if that makes sense (I am about to leave work...) so I will
re-think of it tonight and tell you tomorrow if I got something
interesting (and clear) enough. ;)
Herve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - Jakarta Commons CLI http://jakarta.apache.org/commons/cli
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
