Ugo Cei wrote:
Il giorno 12/ott/04, alle 14:33, [EMAIL PROTECTED] 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 }
