>> Non-regex validations can easily be added. What did
>> you have in mind exactly? Do you mean date, credit
>> cards, etc? I also thought that we could make
>> constants for things like phone numbers, zip, social
>> security, etc., but you could override them if you
>> wanted to.
>
>Just remember, that not everybody lives in USA. I have been working with an
>application, where they had made a nice method to change the language of the screens,
>but all the input field validation were based on American standard. Not very smart.
Things to note like this, in Australia we call them postcode, and have four digits, in
England
they have letters and numbers. We have 8 digit local phone numbers (everywhere else has
6 or 7 I think and a 3 digit area code). We (and Europe) have dates as DD/MM/YYYY,
Japan has dates
as YYYY/MM/DD, Americans have MM/DD/YYYY (Oh why? I constantly ask).
What ever is done, it should probably be in the same way that java.test.* works with an
abstract base class, and then sub-classes that have the implementation, so we
could have DateValidator, with three subclasses (JapaneseDateValidator,
EuorpeanDateValidator
and AmericanDateValidator) as instances, then by using the Locale we could have
DateValidator dateValidator = DateValidator.getDateValidatorInstance(locale);
where locale is the locale defined by Struts from the browser's information. Then
dateValidator would have methods that returned a Date object based on the input.
Although my preference with Date is to use a JavaScript widget that creates date
select lists of Day/Month/Year with textual descriptions so there is no ambiguity.
However it works, DateValidator should also generate the JavaScript for the
client side validation, so all the code sits in one place, so I can have something like
<html:date property="user.birthday" required="true"/>
and the <html:date/> uses DateValidator. Other options include classes such as
CreditCardValidator and <html:creditcard/> (which generates a text field with
JavaScript validation) and so on.
The the ActionForm can check these types first, put them into the errors object,
and then call validate where we can do more complex checking (such as mastercard
credit card type is selected and the credit card number represents a master card).
An alternative is also for something like <html:creditcard/> to generate HTML
that includes name, expiry date, type and number in a compound collection
of HTML (in a table, maybe).
I posted a long time ago some code that does JavaScript validation that I use
all the time.
--
Kumera - a new Open Source Content Management System
for small to medium web sites written in Perl and using XML
http://www.cyber4.org/kumera/index.html
