commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Speakmon" <bspeak...@apache.org>
Subject Re: [validator] urge to commit rising...
Date Tue, 16 Oct 2007 21:03:57 GMT
I added this information to the wiki:
http://wiki.apache.org/jakarta-commons/Validator14ProjectPlan

On 10/11/07, Paul Benedict <pbenedict@apache.org> wrote:
>
> Niall,
>
> Can you add a copy of this email to the Validator wiki? I think this is
> project plan information that's too good to let go.
>
> Paul
>
> On 10/11/07, Ben Speakmon <bspeakmon@apache.org> wrote:
> >
> > 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.4port
> > > 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
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message