commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <>
Subject Re: [validator] urge to commit rising...
Date Thu, 11 Oct 2007 15:16:24 GMT
On 10/9/07, Ben Speakmon <> wrote:
> I've been looking at validator for a week or so since my RL job now requires
> me to support it. To that end I'd like to help out. Eventually I'd want to
> look closely at JSR 303, especially having annotations for fields and
> methods, but for the current work I'm happy to help out on the 1.4 port and
> refactoring. Niall, assuming you're still the leading hand on this, can you
> let me know where I'd be most useful to start with? In the meantime I'm
> going to poke through the code.

Its months since I found any time for validator work. The two main
goals I had for the next validator release was:

1) remove the dependency on ORO for regex support by moving to a
minimum dependency of JDK 1.4 and using java's built in regex.

2) Refactor remaining validation routines into the "o.a.c.routines"
package and deprecate the older ones in o.a.c package.

There are three remaining validation routines which need to be
refactored into the new package: Credit Card, Email and URL. As part
of the refactoring into the new package I took the opportunity to
re-write/improve the validation routines that I've done so far and was
hoping to do the same with the remaining three.

These three IMO should be broken out into smaller validation routines.
For example both URL and Email validation includes validating an IP
address and that logic is useful in its own right and should be
factored out. The same goes for the check digit validation which is
part of the credit card validator. I made a start on this process by
factoring out check digit validation[1] and creating a generic
CodeValidator[2] (which combines regex, min/max length and check
digit). I also have some stuff in-progress that I never committed
(e.g. an IPv4 validator).


This is the vague plan that I had for the remaining routines:

1) Beak out IP address and hostname validation into their own routines.
2) Refactor Emal and URL validation to use the same IP
address/hostname validation
3) Refactor the credit card validator to use the new check digit
validation OR perhaps to use the new CodeValidator

The one issue that I haven't looked at or worked out what to do about
is the logic in the Email validator which strips out comments (see
stripComments() method) - I'm not even sure that logic works correctly
and it also uses an ORO "substitue" method iteratively.

Lastly once the above is done then I was planning on switching the old
validations to use the new versions in the routines package - and
deprecate them. Also decide on a plan of what to do with the
GenericValidator and GenericTypeValidator - we could leave them
unchanged or provide something equivalent in the new routines package
- I had a vague idea to combine them into one class with the methods
from GenericValidator prefixed with "is" (they return boolean) and the
GenericTypeValidator methods prefixed with "validate" (return an
object) - which would be consistent with what I've done in other parts
of the new "routines" package.


> --Ben

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message