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
Herve Quiroz wrote:
Hi Rob,
Months ago, I suggested using [functor] for such a purpose. Don't know if you remember. Here's a quick link:
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=104730670828791&w=2
And you may still provide standard type checkers and converters using the proposed framework.
I understand that [functor] would add another dependency to [CLI]. But it could easily become a "soft dependency" (required to build but not necessarily to run). The main problem is (IMHO) that [functor] is still in the sandbox and thus there's no official binary release (yet).
Regards,
Herve
On Tue, 12 Aug 2003, Rob Oxspring wrote:
I'd envisaged the conversion String->Integer to be handled by some IntegerValidator class attached to the Argument. If this pattern is chosen then I'm not sure how practical overloaded methods would be - the range of types that could be returned would be infinite and we'd have to think about where to draw the line before the number of convenience methods grows too big. I guess the sensible place to draw that line would be for the Java primitives as anything else can easily be cast from an Object anyway.
Of course this is ignoring the fact that an XML configuration would have the full knowledge of which types were needed where. To be honest though I really need to think about the xml2cli thing. I like the idea in principle but I'm really struggling to get a handle on what input would be supplied, what might be generated and how the client code would interact with cli to respond to the chosen options. The end points are still to blurry in my head to see what transformation is needed. But I'll switch the xml stuff to a new thread.
Rob
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
