Ok. So then why dont we do the following
1) check the language
2) check the location
3) translate values entered in that location to the developers "default
format"
4) do the validation based on the converted data.
This way you dont have to worry about 20 different validations for 20
different parts of the world. And, it can be "pluggable", in that if one
day you decide you want to validation for form entry in Norweigan style,
just create the releveant Locals, properties files, and filters for
conversion of the form data for validation.
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 04, 2001 12:42 PM
Subject: Re: Client/Server Side Validation for Struts 1.1
> Yes, you're right.
>
> In this context, we would want the validators to be able to recognize
> _xx as the location (or have a super method that parsed that from the
> locale for them). This would allow us to continue to use the one session
> locale property to cover both situations.
>
> Jonathan wrote:
> >
> > Sorry, but I'm still confused. If the person in Texas wants to see
his/her
> > pages in Spanish, then the zipcode etc that you would enter in a form
could
> > be displayed/entered in any of the following Locals:
> > 1) ES_us
> > 2) ES_es
> > 3) ES_other
> > etc....
> >
> > If you are going to offer the option of entering zipcodes in a "USA"
style
> > but the display language is Spanish, you will have to let the user
choose
> > their language and location, just like they do in Starmedia and Terr.
That
> > means that you make a local for them. How you do this is another story,
as
> > I would vy for some kind of inheritance with the Language being first,
and
> > the Location being and overridable subclass.
>
