Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of apacheben@gmail.com
 designates 209.85.198.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=Inytttkb9YBD7urxR/v9BCVaeNdT99dORZYPE9HsvBK5mtugQ66TxH8us0dZvdlP+0A4IGO0NyvJyj7SROVV5Bbpw3HKoNIZYcHsFogOBorKkv2xsUJObVJq0RxcIkZOjM0zRi8Y8kY/3rrtloyPTOQIoot4yh13W4XSan9trAw=
Message-ID: <6185d22e0710111254g3d6ddd12saf4cb0d4a27d74ae@mail.gmail.com>
Date: Thu, 11 Oct 2007 12:54:54 -0700
From: "Ben Speakmon" <bspeakmon@apache.org>
Sender: apacheben@gmail.com
To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Subject: Re: [validator] urge to commit rising...
In-Reply-To: <55afdc850710110816nc01153fh123acf8231a0fcb4@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_17770_24619242.1192132494432"
References: <6185d22e0710091354p4ad3efd4gf80abb935f14c5e6@mail.gmail.com>
	 <55afdc850710110816nc01153fh123acf8231a0fcb4@mail.gmail.com>

------=_Part_17770_24619242.1192132494432
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Makes perfect sense.

In the spirit of starting slow, I think I'll look at porting oro regexes to
JDK 1.4 first and making sure that all still works. If anyone finds time to
jump on refactoring before I get to it, that's fine with me :)

Ideally I'd like to get a 1.4 release under way after the work Niall
describes is completed to everyone's satisfaction -- again, I have to
support validator at work, and I'd feel better about that if it had recently
gone through a release push. I can't speculate on timeframe other than it
would probably not be before the end of the year due to the other demands on
my time.

On 10/11/07, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>
> On 10/9/07, Ben Speakmon <bspeakmon@apache.org> 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).
>
> [1] http://tinyurl.com/yqdhg8
> [2] http://tinyurl.com/25zo2u
>
> 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.
>
> Niall
>
> > --Ben
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

------=_Part_17770_24619242.1192132494432--