cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [VOTE] Keep Commons Validator (was Re: svn commit: rev 54668 - cocoon/branches/BRANCH_2_1_X/lib)
Date Wed, 13 Oct 2004 09:18:14 GMT
Ugo Cei wrote:

> Il giorno 12/ott/04, alle 14:33, bdelacretaz@apache.org ha scritto:
>
>> set correct commons-validator-1.1.3.jar path (did the guy who's on 
>> stage now mess up? ;-)
>
>
> You bet! But the error slipped by because I had to disable jars 
> validation because of another library that had broken it just a few 
> minutes before ;-)
>
> Anyway, while we're at it, some people *rightfully* pointed out that I 
> shouldn't have added just another dependency only to validate email 
> addresses in CForms. Well, for one thing, at least email addresses 
> validate correctly now, which wasn't the case before. Besides, 
> Commons-validator might be useful elsewhere and it's just 84k. And I 
> was so nice as to write a handful of testcases for it, so should 
> Validator break in a future release, we could be able to catch it early.
>
> On the other hand, I do share those guys' concern over dependencies, 
> so I'd like to ask for the developers' opinions before deciding 
> whether to keep or to remove it. As I see it, we have two options:
>
> 1. [ ] Rip the necessary code from Commons validator and drop it into 
> the email validation rule of CForms (shouldn't be more than a few 
> lines of code, hopefully).
> 2. [ ] Keep it on the assumption that we will use it for something else.
> 3. [ ] Anything else?


At first, integrating Commons Validator looks appealing as it may avoid 
us to write and maintain our own validators, with the added benefit that 
it provides some client-side JS validation.

Now let's look closer at what we can really reuse.

Out of 19 Java classes, only 4 can actually be used in Cocoon: 
CreditCard, Email, ISBN and URL validators. The Field and Form stuff is 
useless, just as the type-oriented validations (int, date, etc) since 
CForms is strongly typed.

I checked the client-side JS which strangely doesn't provide a 
counterpart to all Java classes. Furthermore, the JS mixes actual 
validation logic and user feedback, which uses an alert, meaning we 
can't use the JS files to e.g. add the notification mark besides the 
invalid widgets as we currently do.

So I go for option 1: rip what need and don't include this additional 
dependency.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message