commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Herve Quiroz <herve.qui...@esil.univ-mrs.fr>
Subject Re: [CLI] 2.0 Proposal
Date Mon, 18 Aug 2003 18:35:19 GMT
Rob,


Basically, the Pre- and Post- stuff were to allow the automation of some
task(s). I had submitted the example of setting system properties
according to command line arguments. Quick link:

http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=104697467907519&w=2

To summarize, (post) predicate stuff was to validate arguments. The
difference between PostPredicate and Predicate was necessary before the
option groups were implemented. Now we just need what I called
Predicate. PostProcesses were used for 2 different goals: automatic
conversion (function) and automatic method invocation (procedure).

I see that with your scheme, the Validator thing replaces both the
Predicate and the PostProcess (function) stuff, which is nice (type
checking and conversion at once). Still left is the ability to specify a
task to be performed automatically right after the command line has been
parsed correctly (such as affecting the system properties according to
command line arguments). But in fact, one could just use your Validator
thing to perform such a task. Then the only problem (if I go
hair-splitting) is the name "Validator". So xxxValidator classes should
implement a Function (or similar) interface (but still be called
xxxValidator). The valid(List values) method would become process(List
value) or evaluate(List value) as it is in [functor]. Also, the
according OptionBuilder method should be something more like:

withArgumentProcess(Function function)

This way, we may handle everything from one single method.

Herve.

On Mon, 18 Aug 2003, Rob Oxspring wrote:

> Hi Herve,
>
> I'd forgotten where the suggestion came from but the idea of linking in
> [functor] is still in my head :).
>
> I was thinking about setting up a Validator interface with a single method:
>     void validate(List values) throws ValidationException;
> and allow Arguments to have an attached Validator instance.  When the
> Argument's validate method is called it would delegate to any validator
> object which would be permitted to transform the String values into
> other Objects and would throw a ValidationException on failure.
>
> I was thinking of supplying a selection of standard validators (Integer,
> File, Date?, Class?,...) and then adding a couple of adapters along the
> lines of:
>     UnaryPredicateValidator - wraps a UnaryPredicate and throws
> ValidationException if any of the values result in false.
>     UnaryFunctionValidator - wraps a UnaryFunction and tranforms the
> values accordingly.  Any failure would result in a ValidationException.
> I guess the a wrapper for UnaryProcedure might be an option too but I
> haven't looked into the functor classes for a while.
>
> Done this way I believe the [functor] dependancy can be completely
> optional, at least until [fuctors] is promoted and released.  It also
> means that clients can write custom validators without having to delve
> into [functors], but have the flexibility to plug in any in-house
> functors they already have too.  It doesn't provide as much for
> [functor] to borrow but once it's released we could maybe harden the
> dependancy and factor out some functors to donate back..
>
> Does this cover the usecases you have in mind?  It doesn't feature the
> pre and post varients but I'm not seeing a usecase for those at the
> moment anyway (always happy to be proved wrong though).
>
> Thoughts?
>
> Rob
>

Mime
View raw message