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 2003/10/22 20:12:38 UTC
Re: [CLI] Validation (was 2.x Tasks)
----- Original Message -----
From: "John Keyes" <jb...@mac.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, October 22, 2003 5:10 PM
Subject: Re: [CLI] 2.x Tasks
> <snip/>
>
> > 1.3) Enum Argument Values
> >
> > Options should allow a list of possible values to validate against.
> > Currently this is in StringValidator but would EnumValidator be better
name?
> > StringArrayValidator is also a suggested name.
> >
> >
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=102750803811805&w=2
> >
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103951380212779&w=2
>
> I have renamed the StringValidator.
>
> We should not modify the List that is passed to the validate
> method. It can lead to behaviour not defined by the API e.g.
But we could define the behaviour with a few comments :)
>
> (taken from DateValidatorTest):
> final Object[] array = new Object[] { "23/12/03", "2002-10-12" };
> final List list = Arrays.asList(array);
> validator.validate(list);
>
> This will actually modify 'array' (see Arrays.asList). This smells.
I can definitely understand your thinking but it is a feature I thought was
quiet handy too. In the example of DateValidator, checking the string is a
valid date involves the creation of a Date object and it seems silly to
throw that instance away when we're only going to recreate it later. If you
really don't like the idea of modifying the list parameter I suppose we
could change the sig to List validate(List) (Although you should be aware
that at least DefaultOption's process() method modifies it's ListIterator).
>
> I think we should leave the Validator as is and not
> perform any instance creation. In CLI 1 there was
> an optional type attribute for Arguments
> (java.lang.Class). The value of an Argument could
> be retrieved using two different methods:
>
> CommandLine.getOptionValue : String
> CommandLine.getOptionObject : Object
>
> The getOptionObject created the relevant instance from
> the string value.
The way I see it is that for any given option you either want it as a String
or an Object. If your validator has checked you have a valid Date or Number
then I can't see why you would ever want to get to the original String
version back rather than the richer objects. I've got no objection to a
convenience method performing the common cast-to-String, but I don't see the
need to delay the transformation until the interrogation phase.
Rob
>
> I think we should use a similar mechanism now.
>
> -John K
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] Validation (was 2.x Tasks)
Posted by John Keyes <jb...@mac.com>.
> The word "normalize" has just hopped into my head. Does that cover
> "validate and maybe convert" to you?
That sounds good. Any idea for the interface
name?
> The caching approach would work but it seems a lot of work to get
> around a bad choice of name for the method/class.
Yeah you're right.
-John K
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] Validation (was 2.x Tasks)
Posted by Rob Oxspring <ro...@imapmail.org>.
----- Original Message -----
From: "John Keyes" <jb...@mac.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, October 22, 2003 7:50 PM
Subject: Re: [CLI] Validation (was 2.x Tasks)
> <snip/>
>
> > I can definitely understand your thinking but it is a feature I thought
was
> > quiet handy too. In the example of DateValidator, checking the string
is a
> > valid date involves the creation of a Date object and it seems silly to
> > throw that instance away when we're only going to recreate it later. If
you
> > really don't like the idea of modifying the list parameter I suppose we
> > could change the sig to List validate(List) (Although you should be
aware
> > that at least DefaultOption's process() method modifies it's
ListIterator).
>
> Maybe calling it a Validator is incorrect then. I had thought
> of changing the method to return a List but then it is no longer
> a validation method, it is a validation and conversion method.
Yeah - the name is stretching the definition a bit. The loose justification
in my head for DateValidator was "it ensures the values are valid Date
objects" which sounded like validation.
>
> We could modify the signature as follows:
>
> void validate(Option, List)
>
> The new values can be set on the Option rather than modifying
> the list.
Well it would need a CommandLine parameter too but it would work.
>
> Or we could define a new interface that extends Validator
> with one method that returns a List (the object instances).
> So validators can implement Validator and validators/convertors
> can implement this new interface (not sure what name to give it).
> To avoid throwing away the newly created objects we could cache
> the results in the validate method and return them via the
> new method.
The word "normalize" has just hopped into my head. Does that cover "validate
and maybe convert" to you?
The caching approach would work but it seems a lot of work to get around a
bad choice of name for the method/class.
Rob
>
> I've started to ramble now so I should stop ;)
>
> -John K
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] Validation (was 2.x Tasks)
Posted by John Keyes <jb...@mac.com>.
<snip/>
> I can definitely understand your thinking but it is a feature I thought was
> quiet handy too. In the example of DateValidator, checking the string is a
> valid date involves the creation of a Date object and it seems silly to
> throw that instance away when we're only going to recreate it later. If you
> really don't like the idea of modifying the list parameter I suppose we
> could change the sig to List validate(List) (Although you should be aware
> that at least DefaultOption's process() method modifies it's ListIterator).
Maybe calling it a Validator is incorrect then. I had thought
of changing the method to return a List but then it is no longer
a validation method, it is a validation and conversion method.
We could modify the signature as follows:
void validate(Option, List)
The new values can be set on the Option rather than modifying
the list.
Or we could define a new interface that extends Validator
with one method that returns a List (the object instances).
So validators can implement Validator and validators/convertors
can implement this new interface (not sure what name to give it).
To avoid throwing away the newly created objects we could cache
the results in the validate method and return them via the
new method.
I've started to ramble now so I should stop ;)
-John K
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org