I added this information to the wiki: http://wiki.apache.org/jakarta-commons/Validator14ProjectPlan
On 10/11/07, Paul Benedict <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > > On 10/9/07, Ben Speakmon <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > >
