Client/Server Side Validation for Struts 1.1

[David Winterfeldt <dw...@yahoo.com>]

I'd like to get a discussion started on the
client/standard validations for Struts 1.1.  I thought
it would be good to talk about what basic features it
would include and implementation.  Here are the
descriptions from the To Do list for 1.1.

Standard Validations. 
Add the ability to configure standard validations on
particular properties to be enforced by the controller
servlet automatically. Where feasible, client-side
JavaScript validations may also be generated based on
the same configuration rules. 

Client Side Validation. 
Add the ability to automatically generate optional
JavaScript code to perform client-side validations for
things like required fields, numeric fields,
dates/times/timestamps, and so on. The required
validation should mesh with validation enhancements
provided in the controller servlet itself.

Nic Hobbs and I have both volunteered for the Standard
(Server Side) Validations and Ted Husted, Nic Hobbs,
Spencer Smith and I have volunteered for the Client
Validations (JavaScript).  Ted has been using a
validation framework I've done on a project (I'm not
sure what version).  It lets you define your
validation rules in an xml file.  It supports
internationalized rules for a form and
internationalized messages.  It has basic support for
creating JavaScript methods that can do what a server
side method does. The code, documentation, and example
webapps are posted here.  And of course Struts is
welcome to the source code if everyone thinks that
what I've done so far is good foundation to start on.
http://home.earthlink.net/~dwinterfeldt/

If any of the other volunteers have started something,
I'd like to see it and I'm sure everyone has ideas for
the design.  I'd go into more detail about everything
I've done, but it is probably easier for anyone
interested to go to my site and read the documentation
and javadocs posted there.

David Winterfeldt
http://home.earthlink.net/~dwinterfeldt/

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Re: Client/Server Side Validation for Struts 1.1

[Ted Husted <hu...@apache.org>]

"Deadman, Hal" wrote:
> I think it overly complicates things to deal with forms based on a user's
> selected locale. I do think formating for display should take into account
> the locale.

Agreed. Part of it is that we're now thinking about an omnibus object,
or package of objects, not directly linked to Struts, that would handle
data-type validations, data-type conversions, and then transformations
into formatted Strings for presentation. So this utility might work both
sides of the IO fence. 

-Ted.

RE: Client/Server Side Validation for Struts 1.1

["Deadman, Hal" <ha...@tallan.com>]

Forcing a phone number or zip code to match some regular expression doesn't
really make it valid. The only way to validate that kind of thing is to
interface with an address verification system and that is only available in
relatively few countries.

It's in a users best interest to enter a valid address if they expect you to
send them something. If you aren't sending them something, what do you want
the information for?

My "solution" to a form meant to be used by users in multiple countries
would be to make it as general and accepting as possible. Maybe I would have
a drop-down for US states and then have a "province" field that is only
required if the state is not selected. Users will figure out how to get
their address into the form and the mailman will figure out to deliver it.

If a user wants to enter crap, they can still do it with regular expression
"validation". The purpose of validation should be to catch careless errors.
If it's not worth it to the user to enter valid data, don't expect it to be
valid.

I think it overly complicates things to deal with forms based on a user's
selected locale. I do think formating for display should take into account
the locale.

Hal

> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Monday, June 04, 2001 12:13 PM
> To: struts-dev@jakarta.apache.org
> Subject: Re: Client/Server Side Validation for Struts 1.1
>
>
> We're not only talking just about language now, we're talking about
> validating things like telephone numbers and postal codes based where
> the user is located, regardless of what language they prefer.
> Michael's
> example was a Spanish-speaking resident in the US, who might be in the
> ES locale as to language, but would be in the US location as to
> telephone and postal code. I run into this myself, since we are on the
> Canadian border. We share the same telephone format but
> different postal
> codes. So, during validation we need more granularity than what is
> usually associated with locales.
>
> Perhaps some applications need two "locale" settings, one for language
> preference and another for location, and our validation routines may
> need to be written to recognize that.
>
> Jonathan wrote:
> >
> > I am still confused as to why this is all an issue if the
> user can select
> > the languange of their choice.  If it is an automatic
> thing, like if the
> > server is reading the preferred language strings in the
> header, then maybe
> > you have an issue becuase the Local is not selected by the
> user.  It boils
> > down to what language the user wants to see the pages
> displayed in.  Check
> > out the following sites: www.terra.com www.starmedia.com
> > http://www.dgolpe.com In each case the user SELECTS the
> language of choice.
>

Re: Client/Server Side Validation for Struts 1.1

[Ted Husted <hu...@apache.org>]

Michael Westbay wrote:
> One question, what's the default fall-back?  With the suffixes being added,
> one could have no suffix as the fall back option.  But what about
> picture-tokens?  locale="DEFAULT"?

If we did something like this (and this is all very preliminary
whiteboard stuff, so we might not), how about locale="*", and have
anything not overridden in a specific locale fall through.

Re: Client/Server Side Validation for Struts 1.1

[Michael Westbay <we...@seaple.icc.ne.jp>]

Husted-san wrote:

> One way to go would be to support a second set of resources, named for
> the country-code portion of the locale (_us, _ca). These would all have
> the same properties, just like the language resources, but use different
> masks and picture tokens for different countries. [...]

Thank you.  This clarifies that the language and location are separate, 
eliminating the need to permutate all combinations.

> [...]  We could put these in separate files, or just make them
> sections of the validation.xml.
>
> <picture-tokens locale="_au">
> tel = ## ######
> </picture-tokens>

One file to handle the world?  That'd be nice.  At first I was taken back by 
the idea that some may just want to target a niche market and not need to 
deliver throughout the world.  But then, they wouldn't need this package, 
either.

One question, what's the default fall-back?  With the suffixes being added, 
one could have no suffix as the fall back option.  But what about 
picture-tokens?  locale="DEFAULT"?

> Mixing country-code resources in with language resources would not be
> useful, since the core point of the language resources is that you can
> hand it over to a translator, and the country-code resources would not
> need to be translated by that person.

That was the point I was trying to make.  You make it sound much better.  
Thank you.

I don't mean to be patronizing, but l10n and i18n fascinates me.  It presents 
a number of interesting problems, many of which can be simulated and thrown 
out before a design is decided on.  It's just better to catch those problems 
early on, so I'm trying to get a clearer picture of what you have in mind.

I feel the design is shaping up much more clearly now.  Not done, but I can't 
see any major stumbling blocks (at the moment).  Thank you again for the 
clarifications.

-- 
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home:           http://www.seaple.icc.ne.jp/~westbay
Commentary:     http://www.japanesebaseball.com/

Re: Client/Server Side Validation for Struts 1.1

[Ted Husted <hu...@apache.org>]

One way to go would be to support a second set of resources, named for
the country-code portion of the locale (_us, _ca). These would all have
the same properties, just like the language resoruces, but use different
masks and picture tokens for different countries. So we might have
something like 

_us 

tel = (###) ###-####
post = #####[-####]

_ca

tel = (###) ###-####
post = #@# @#@

_au

tel = ## ######

and so forth. We could put these in seperate files, or just make them
sections of the validation.xml.

<picture-tokens locale="_au">
tel = ## ######
</picture-tokens>

In practice, an i18n application like this would probably start with a
broad set of default validations, and ask the user to indicate their
location (country code), and then apply the appropriate server-side
validation or transformation based on that. 

Mixing country-code resources in with language resources would not be
useful, since the core point of the language resources is that you can
hand it over to a translator, and the country-code resources would not
need to be translated by that person.

Michael Westbay wrote:
> 
> Husted-san wrote:
> 
> > 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.
> 
> But what kind of compexity are you looking at?  Let's take a small example of
> languages and countries to cover:
> 
> Languages:  English, Spainish, Japanese
> Locales:  U.S., England, Spain, Japan
> 
> Now you need resources:
> 
>   en, en_US, en_UK, en_ES, en_JP
>   es, es_US, es_UK, es_ES, es_JP
>   ja, ja_US, ja_UK, ja_ES, ja_JP
> 
> Add a language, multiply by 5.
> Add a country, multipy the result by 4.
> 
> And most of the strings will be repeated over and over ad. nasuim.
> 
> It seems to me that the target locale (meaning place) should be separate with
> some sort of formatted strings like "(###)###-####".
> 
> Units of measure (dollars, yet, pesos) etc. can be localized in the language
> file, as well as display order.  For example:
> 
>   Language_en.properties:
>     usdollar_value=US$ {0}
>     yen_value={0} yen
>     peso_value={0} pesos
> 
>   Language_ja.properties:
>     usdollar_value={0}$B%I%k(B
>     yen_value={0}$B1_(B
>     peso_value={0}$B%Z%=(B
> 
> This way, the formatting/format checking "0.00" or "#.##" can be written
> once, and used by all of the languagues.
> 
> This still doesn't cover the problem with providing a choice of two
> currencies (as in the EC).  Any suggestions?
> 
> --
> Michael Westbay
> Work: Beacon-IT http://www.beacon-it.co.jp/
> Home:           http://www.seaple.icc.ne.jp/~westbay
> Commentary:     http://www.japanesebaseball.com/

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/

Re: Client/Server Side Validation for Struts 1.1

[Paul Speed <Pa...@metrixpoint.com>]

Another thing to consider along these lines is just going full-force
with typing.  I've done this in the past for measurement systems and
it worked out very well.

Rather than having a bunch of BigDecimals hanging around with values
of different "types", you could create specific subclasses for the
various monetary types you want to support.  It's a little painful
but it's really the only way the business layer and presentation
layer can avoid the confusion that's bound to arise.  So if an object
is a Euro you display it as such, if it's a Dollar you display it as
dollars, etc..  That way you don't end up accidentally displaying
a dollar amount as pounds since the presentation layer can be smart
enough to format the type appropriately.

-Paul Speed

William Jaynes wrote:
> 
> Remember... separation of view from model. The act of displaying an
> amount in a particular currency format is separate from determining what
> that amount is. So the code used to implement the display of the amount
> should not be mixed up with the code used to determine the amount.
> 
> ----- Original Message -----
> From: "Jonathan Asbell" <ja...@i-2000.com>
> To: <st...@jakarta.apache.org>
> Sent: Tuesday, June 05, 2001 7:40 AM
> Subject: Re: Client/Server Side Validation for Struts 1.1
> 
> > Ok, so why then is this an issue.  What is the value of seeing Pounds
> AND
> > Euros on the same page if you dont want to realte their rates.  Ok, so
> I
> > could enter data using pounds, or enter data using Euros depending on
> my
> > personalization setting.  But what is the use of DISPLAYING both if
> you wont
> > give me then conversion?
> >
> > By the way Ted, you are up early man.  I guess it finally thawed out
> upstate
> > ;^>
> >
> > ----- Original Message -----
> > From: "Ted Husted" <hu...@apache.org>
> > To: <st...@jakarta.apache.org>
> > Sent: Tuesday, June 05, 2001 7:28 AM
> > Subject: Re: Client/Server Side Validation for Struts 1.1
> >
> >
> > > Wouldn't exchange rates count as business logic?
> > >
> > > I think the thrust here is the ability to take a given binary number
> and
> > > display it using the currency sign and format ($###.## vs ###,##DM]
> for
> > > a given nation. This package would consider the value immutable.
> Another
> > > player would have to change the binary value first, and then pass it
> > > along for formatting.
> > >
> > > Jonathan Asbell wrote:
> > > >
> > > > "Tonarino kyacua, yoku-ki-ka-ku Kyuacuda"
> > > >
> > > > What about allowing two or three different displays of currency,
> but
> > only
> > > > one type of currency for data entry.  That way I could be in
> England
> > > > entering pounds, but seeing display values in Pounds, Hong Kong $,
> and
> > Euro.
> > > > Of course this keeps making me think that at this point we are
> talking
> > about
> > > > accessing the current exchange rates, which than you would need a
> feed
> > etc.
> > > > This IS true because thereare countries in SOuth america whos
> currency
> > jumps
> > > > and dives each week, and you would not be presenting viewers with
> the
> > > > correct exchange.
> > >
> >

Re: Client/Server Side Validation for Struts 1.1

["Craig R. McClanahan" <cr...@apache.org>]

On Tue, 5 Jun 2001, William Jaynes wrote:

> Remember... separation of view from model. The act of displaying an
> amount in a particular currency format is separate from determining what
> that amount is. So the code used to implement the display of the amount
> should not be mixed up with the code used to determine the amount.
> 

When I was building multi-currency apps in Europe, the rule was you needed
to keep the amount, the currency, and the date -- conversion rates between
currencies are not static.  Then, you need some mechanism to perform
conversions for you that is date sensitive. The Euro made life simpler
(because it fixed the conversion rates within the EC), but the problem did
not completely go away.

Craig

Re: Client/Server Side Validation for Struts 1.1

[William Jaynes <wj...@mediaone.net>]

Remember... separation of view from model. The act of displaying an
amount in a particular currency format is separate from determining what
that amount is. So the code used to implement the display of the amount
should not be mixed up with the code used to determine the amount.

----- Original Message -----
From: "Jonathan Asbell" <ja...@i-2000.com>
To: <st...@jakarta.apache.org>
Sent: Tuesday, June 05, 2001 7:40 AM
Subject: Re: Client/Server Side Validation for Struts 1.1


> Ok, so why then is this an issue.  What is the value of seeing Pounds
AND
> Euros on the same page if you dont want to realte their rates.  Ok, so
I
> could enter data using pounds, or enter data using Euros depending on
my
> personalization setting.  But what is the use of DISPLAYING both if
you wont
> give me then conversion?
>
> By the way Ted, you are up early man.  I guess it finally thawed out
upstate
> ;^>
>
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Tuesday, June 05, 2001 7:28 AM
> Subject: Re: Client/Server Side Validation for Struts 1.1
>
>
> > Wouldn't exchange rates count as business logic?
> >
> > I think the thrust here is the ability to take a given binary number
and
> > display it using the currency sign and format ($###.## vs ###,##DM]
for
> > a given nation. This package would consider the value immutable.
Another
> > player would have to change the binary value first, and then pass it
> > along for formatting.
> >
> > Jonathan Asbell wrote:
> > >
> > > "Tonarino kyacua, yoku-ki-ka-ku Kyuacuda"
> > >
> > > What about allowing two or three different displays of currency,
but
> only
> > > one type of currency for data entry.  That way I could be in
England
> > > entering pounds, but seeing display values in Pounds, Hong Kong $,
and
> Euro.
> > > Of course this keeps making me think that at this point we are
talking
> about
> > > accessing the current exchange rates, which than you would need a
feed
> etc.
> > > This IS true because thereare countries in SOuth america whos
currency
> jumps
> > > and dives each week, and you would not be presenting viewers with
the
> > > correct exchange.
> >
>

Re: Client/Server Side Validation for Struts 1.1

[Jonathan Asbell <ja...@i-2000.com>]

Ok, so why then is this an issue.  What is the value of seeing Pounds AND
Euros on the same page if you dont want to realte their rates.  Ok, so I
could enter data using pounds, or enter data using Euros depending on my
personalization setting.  But what is the use of DISPLAYING both if you wont
give me then conversion?

By the way Ted, you are up early man.  I guess it finally thawed out upstate
;^>

----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Tuesday, June 05, 2001 7:28 AM
Subject: Re: Client/Server Side Validation for Struts 1.1


> Wouldn't exchange rates count as business logic?
>
> I think the thrust here is the ability to take a given binary number and
> display it using the currency sign and format ($###.## vs ###,##DM] for
> a given nation. This package would consider the value immutable. Another
> player would have to change the binary value first, and then pass it
> along for formatting.
>
> Jonathan Asbell wrote:
> >
> > "Tonarino kyacua, yoku-ki-ka-ku Kyuacuda"
> >
> > What about allowing two or three different displays of currency, but
only
> > one type of currency for data entry.  That way I could be in England
> > entering pounds, but seeing display values in Pounds, Hong Kong $, and
Euro.
> > Of course this keeps making me think that at this point we are talking
about
> > accessing the current exchange rates, which than you would need a feed
etc.
> > This IS true because thereare countries in SOuth america whos currency
jumps
> > and dives each week, and you would not be presenting viewers with the
> > correct exchange.
>

Re: Client/Server Side Validation for Struts 1.1

[Ted Husted <hu...@apache.org>]

Wouldn't exchange rates count as business logic?

I think the thrust here is the ability to take a given binary number and
display it using the currency sign and format ($###.## vs ###,##DM] for
a given nation. This package would consider the value immutable. Another
player would have to change the binary value first, and then pass it
along for formatting. 

Jonathan Asbell wrote:
> 
> "Tonarino kyacua, yoku-ki-ka-ku Kyuacuda"
> 
> What about allowing two or three different displays of currency, but only
> one type of currency for data entry.  That way I could be in England
> entering pounds, but seeing display values in Pounds, Hong Kong $, and Euro.
> Of course this keeps making me think that at this point we are talking about
> accessing the current exchange rates, which than you would need a feed etc.
> This IS true because thereare countries in SOuth america whos currency jumps
> and dives each week, and you would not be presenting viewers with the
> correct exchange.

Re: Client/Server Side Validation for Struts 1.1

[Jonathan Asbell <ja...@i-2000.com>]

"Tonarino kyacua, yoku-ki-ka-ku Kyuacuda"

What about allowing two or three different displays of currency, but only
one type of currency for data entry.  That way I could be in England
entering pounds, but seeing display values in Pounds, Hong Kong $, and Euro.
Of course this keeps making me think that at this point we are talking about
accessing the current exchange rates, which than you would need a feed etc.
This IS true because thereare countries in SOuth america whos currency jumps
and dives each week, and you would not be presenting viewers with the
correct exchange.

----- Original Message -----
From: "Michael Westbay" <we...@seaple.icc.ne.jp>
To: <st...@jakarta.apache.org>
Sent: Monday, June 04, 2001 7:33 PM
Subject: Re: Client/Server Side Validation for Struts 1.1


> Husted-san wrote:
>
> > 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.
>
> But what kind of compexity are you looking at?  Let's take a small example
of
> languages and countries to cover:
>
> Languages:  English, Spainish, Japanese
> Locales:  U.S., England, Spain, Japan
>
> Now you need resources:
>
>   en, en_US, en_UK, en_ES, en_JP
>   es, es_US, es_UK, es_ES, es_JP
>   ja, ja_US, ja_UK, ja_ES, ja_JP
>
> Add a language, multiply by 5.
> Add a country, multipy the result by 4.
>
> And most of the strings will be repeated over and over ad. nasuim.
>
> It seems to me that the target locale (meaning place) should be separate
with
> some sort of formatted strings like "(###)###-####".
>
> Units of measure (dollars, yet, pesos) etc. can be localized in the
language
> file, as well as display order.  For example:
>
>   Language_en.properties:
>     usdollar_value=US$ {0}
>     yen_value={0} yen
>     peso_value={0} pesos
>
>   Language_ja.properties:
>     usdollar_value={0}ドル
>     yen_value={0}円
>     peso_value={0}ペソ
>
> This way, the formatting/format checking "0.00" or "#.##" can be written
> once, and used by all of the languagues.
>
> This still doesn't cover the problem with providing a choice of two
> currencies (as in the EC).  Any suggestions?
>
> --
> Michael Westbay
> Work: Beacon-IT http://www.beacon-it.co.jp/
> Home:           http://www.seaple.icc.ne.jp/~westbay
> Commentary:     http://www.japanesebaseball.com/
>

Re: Client/Server Side Validation for Struts 1.1

["Craig R. McClanahan" <cr...@apache.org>]

On Tue, 5 Jun 2001, Michael Westbay wrote:

> 
> But what kind of compexity are you looking at?  Let's take a small example of 
> languages and countries to cover:
> 
> Languages:  English, Spainish, Japanese
> Locales:  U.S., England, Spain, Japan
> 
> Now you need resources:
> 
>   en, en_US, en_UK, en_ES, en_JP
>   es, es_US, es_UK, es_ES, es_JP
>   ja, ja_US, ja_UK, ja_ES, ja_JP
> 
> Add a language, multiply by 5.
> Add a country, multipy the result by 4.
> 
> And most of the strings will be repeated over and over ad. nasuim.
> 

I'm not totally caught up on this thread, so someone else might have noted
this already -- but the resource bundle classes do not (and our
validator mechanism should not, if based on locales) require repeating the
message strings in every single case.  For example, if the current user
has selected locale xx_YY, the message will be looked up in
* xx_YY (if it exists), else
* xx (if it exists), else
* the default Locale for the server.

Thus, for messages and formats that are common to all English speakers
independent of location, should be placed only in the resources for the
"en" Locale.

> It seems to me that the target locale (meaning place) should be separate with 
> some sort of formatted strings like "(###)###-####".
> 
> Units of measure (dollars, yet, pesos) etc. can be localized in the language 
> file, as well as display order.  For example:
> 
>   Language_en.properties:
>     usdollar_value=US$ {0}
>     yen_value={0} yen
>     peso_value={0} pesos
> 
>   Language_ja.properties:
>     usdollar_value={0}$B%I%k(B
>     yen_value={0}$B1_(B
>     peso_value={0}$B%Z%=(B
> 
> This way, the formatting/format checking "0.00" or "#.##" can be written 
> once, and used by all of the languagues.
> 
> This still doesn't cover the problem with providing a choice of two 
> currencies (as in the EC).  Any suggestions?
> 

It's also more complicated than that in another direction.  If I've
selected the "en_US" Locale for myself, but I'm entering an address in
France, wouldn't I want to use the French postal code format strings?  In
other words, validation formats for one field might depend on the data
content of another field.

> Michael Westbay

Craig McClanahan

Re: Client/Server Side Validation for Struts 1.1

[Michael Westbay <we...@seaple.icc.ne.jp>]

Husted-san wrote:

> 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.

But what kind of compexity are you looking at?  Let's take a small example of 
languages and countries to cover:

Languages:  English, Spainish, Japanese
Locales:  U.S., England, Spain, Japan

Now you need resources:

  en, en_US, en_UK, en_ES, en_JP
  es, es_US, es_UK, es_ES, es_JP
  ja, ja_US, ja_UK, ja_ES, ja_JP

Add a language, multiply by 5.
Add a country, multipy the result by 4.

And most of the strings will be repeated over and over ad. nasuim.

It seems to me that the target locale (meaning place) should be separate with 
some sort of formatted strings like "(###)###-####".

Units of measure (dollars, yet, pesos) etc. can be localized in the language 
file, as well as display order.  For example:

  Language_en.properties:
    usdollar_value=US$ {0}
    yen_value={0} yen
    peso_value={0} pesos

  Language_ja.properties:
    usdollar_value={0}ドル
    yen_value={0}円
    peso_value={0}ペソ

This way, the formatting/format checking "0.00" or "#.##" can be written 
once, and used by all of the languagues.

This still doesn't cover the problem with providing a choice of two 
currencies (as in the EC).  Any suggestions?

-- 
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home:           http://www.seaple.icc.ne.jp/~westbay
Commentary:     http://www.japanesebaseball.com/

Re: Client/Server Side Validation for Struts 1.1

[Jonathan <ja...@i-2000.com>]

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" <hu...@apache.org>
To: <st...@jakarta.apache.org>
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.
>

Re: Client/Server Side Validation for Struts 1.1

[Ted Husted <hu...@apache.org>]

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.

Re: Client/Server Side Validation for Struts 1.1

[Jonathan <ja...@i-2000.com>]

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.


----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Monday, June 04, 2001 12:12 PM
Subject: Re: Client/Server Side Validation for Struts 1.1


> We're not only talking just about language now, we're talking about
> validating things like telephone numbers and postal codes based where
> the user is located, regardless of what language they prefer. Michael's
> example was a Spanish-speaking resident in the US, who might be in the
> ES locale as to language, but would be in the US location as to
> telephone and postal code. I run into this myself, since we are on the
> Canadian border. We share the same telephone format but different postal
> codes. So, during validation we need more granularity than what is
> usually associated with locales.
>
> Perhaps some applications need two "locale" settings, one for language
> preference and another for location, and our validation routines may
> need to be written to recognize that.
>
> Jonathan wrote:
> >
> > I am still confused as to why this is all an issue if the user can
select
> > the languange of their choice.  If it is an automatic thing, like if the
> > server is reading the preferred language strings in the header, then
maybe
> > you have an issue becuase the Local is not selected by the user.  It
boils
> > down to what language the user wants to see the pages displayed in.
Check
> > out the following sites: www.terra.com www.starmedia.com
> > http://www.dgolpe.com In each case the user SELECTS the language of
choice.
>

Re: Client/Server Side Validation for Struts 1.1

[Ted Husted <hu...@apache.org>]

We're not only talking just about language now, we're talking about
validating things like telephone numbers and postal codes based where
the user is located, regardless of what language they prefer. Michael's
example was a Spanish-speaking resident in the US, who might be in the
ES locale as to language, but would be in the US location as to
telephone and postal code. I run into this myself, since we are on the
Canadian border. We share the same telephone format but different postal
codes. So, during validation we need more granularity than what is
usually associated with locales. 

Perhaps some applications need two "locale" settings, one for language
preference and another for location, and our validation routines may
need to be written to recognize that.

Jonathan wrote:
> 
> I am still confused as to why this is all an issue if the user can select
> the languange of their choice.  If it is an automatic thing, like if the
> server is reading the preferred language strings in the header, then maybe
> you have an issue becuase the Local is not selected by the user.  It boils
> down to what language the user wants to see the pages displayed in.  Check
> out the following sites: www.terra.com www.starmedia.com
> http://www.dgolpe.com In each case the user SELECTS the language of choice.

Re: Client/Server Side Validation for Struts 1.1

[Jonathan <ja...@i-2000.com>]

I am still confused as to why this is all an issue if the user can select
the languange of their choice.  If it is an automatic thing, like if the
server is reading the preferred language strings in the header, then maybe
you have an issue becuase the Local is not selected by the user.  It boils
down to what language the user wants to see the pages displayed in.  Check
out the following sites: www.terra.com www.starmedia.com
http://www.dgolpe.com In each case the user SELECTS the language of choice.


----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Monday, June 04, 2001 10:32 AM
Subject: Re: Client/Server Side Validation for Struts 1.1


> I believe that would happen under the current model. The validate
> servlet is keyed to the user's locale, and would returns the language
> elements for that locale regardless of where the error originated.
>
> The validator servlet understands that the properties may have different
> labels in different locales, but the programtic property name remains
> the same. The property may be "nomme", but the label may be "name"  for
> the EN locale.
>
> Michael was pointing out that someone might select ES as their "locale",
> since they speak Spanish, but may be living in California. So there
> needs to be a distinction between language and location.
>
> Jonathan Asbell wrote:
> >
> > Just a question.  Why dont you look at resolving validations the same
way we
> > look resolving data in a database or parameter names?  That is you dont
> > store the parameter names in i18n text, just the values.  You dont store
the
> > database columns as i18n column names, just the data. Maybe we could
have a
> > "Local converter" which sees what local you are using, knows that text
will
> > be entered in i18n, and converts the i18n form data into the default
Local
> > format, THEN validate.  What I'm saying is that we make a copy of the
form
> > data, convert it first then validate, and a bad validation for a
currency
> > separator would say in the persons language "you are missing a currency
> > separator", send back the original value that was copied along with the
> > error message in the persons language
> >
> > ----- Original Message -----
> > From: "Ted Husted" <hu...@apache.org>
> > To: <st...@jakarta.apache.org>
> > Sent: Monday, June 04, 2001 8:54 AM
> > Subject: Re: Client/Server Side Validation for Struts 1.1
> >
> > > Good points, Michael.
> > >
> > > Language is one thing, location is another, and right now Java i18n
does
> > > seem to infer location from language.
> > >
> > > In practice, this says that if they choose country XX on a
> > > contact form, then they should get the validations for country XX,
> > > regardless of any global XX locale setting. Of course, the same
> > > mechanism
> > > could apply to any number of validations, where the selection on one
> > > field affects what is valid in another.
> > >
> > > My first inclination would be to provide a broad validation in the
> > > FormSet (no letters in a telephone field (*)), and then perform a more
> > > complete validation server-side by invoking a specific validator (if I
> > > have one) for country XX.
> > >
> > > Of course, it would also be cool to support dynamic controls, where if
> > > they chose a different location (or whatever) on the form, the runtime
> > > validations on other fields would also change.
> > >
> > > -Ted.
> > >
> > > (*) At least telephone numbers should be letter-free now. As a child
> > > in the US, our telephone number was expressed as EXPORT 29156, which
> > > resolved to 3929156. Apparently we could not be trusted to remember
> > > 7 numbers back then ;-)
> > >
> > > Michael Westbay wrote:
> > > >
> > > > Husted-san wrote:
> > > >
> > > > > The validation.xml supports creating FormSets for different
locales.
> > > >
> > > > Wait a second.  You just said "locales" right?  Yet what are Java
> > locales
> > > > used for?  Language.
> > > >
> > > > I live in Japan, however, if I'm browsing in English, what kind of
phone
> > > > number am I going to get?  Dose the web designer need to write a
en_JP
> > > > locale?  How about Spanish speakers in California?
> > > >
> > > > The name "locale" has always bothered me with Java, because it tends
to
> > be
> > > > used to define a language rather than a place.  Yes, there are en_UK
and
> > > > en_US versions, but even those are for differences in language
> > expressions
> > > > more than location.
> > > >
> > > > Now, let's say that my wife, born in Mexico, raised in the U.S., and
now
> > > > living in Japan, is surfing the Web in Spanish, and wants to send a
> > present
> > > > to a friend in Brazil.  She's asked to enter a zip code.  What
"locale"
> > will
> > > > be presented to her?
> > > >
> > > > Perhaps I missed something somewhere along the line where "locale"
was
> > > > differentiated from "language" resources.  It's probably just a
> > semantics
> > > > problem as you all have probably been thinking all along that the
checks
> > are
> > > > to be done based on the country that the user enters in a form, not
the
> > > > "locale" to which (s)he is surfing.  But that'll be something else
that
> > one
> > > > must keep in mind when solidifying a spec.
> > > >
> > > > Sorry, but even though "locale" is probably the correct word here,
it's
> > kind
> > > > of confusing in the context of i18n in Java.
> > > >
> > > > --
> > > > Michael Westbay
> > > > Work: Beacon-IT http://www.beacon-it.co.jp/
> > > > Home:           http://www.seaple.icc.ne.jp/~westbay
> > > > Commentary:     http://www.japanesebaseball.com/
> > >
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>

Re: Client/Server Side Validation for Struts 1.1

[David Winterfeldt <dw...@yahoo.com>]

The validation framework uses the Locale object placed
in session scope for the user.

This is how the ResourceBundle works.
http://java.sun.com/j2se/1.3/docs/api/java/util/ResourceBundle.html

For example, if the current default locale is en_US,
the locale the caller is interested in is fr_CH, and
the resource bundle name is MyResources, resource
bundle lookup will search for the following classes,
in order: 
MyResources_fr_CH 
MyResources_fr 
MyResources_en_US 
MyResources_en 
MyResources 

I've made the validation framework work the same way. 
You should define a general language before you start
defining specific ones unless you don't want someone
from another region to access you're resource because
it is too specific to that region.  So if you create a
resource file for english then anyone from en_US or
en_JP will first look for a specific match, but then
will look for just the language.

David

--- Ted Husted <hu...@apache.org> wrote:
> I believe that would happen under the current model.
> The validate
> servlet is keyed to the user's locale, and would
> returns the language
> elements for that locale regardless of where the
> error originated. 
> 
> The validator servlet understands that the
> properties may have different
> labels in different locales, but the programtic
> property name remains
> the same. The property may be "nomme", but the label
> may be "name"  for
> the EN locale.
> 
> Michael was pointing out that someone might select
> ES as their "locale",
> since they speak Spanish, but may be living in
> California. So there
> needs to be a distinction between language and
> location.
> 
> Jonathan Asbell wrote:
> > 
> > Just a question.  Why dont you look at resolving
> validations the same way we
> > look resolving data in a database or parameter
> names?  That is you dont
> > store the parameter names in i18n text, just the
> values.  You dont store the
> > database columns as i18n column names, just the
> data. Maybe we could have a
> > "Local converter" which sees what local you are
> using, knows that text will
> > be entered in i18n, and converts the i18n form
> data into the default Local
> > format, THEN validate.  What I'm saying is that we
> make a copy of the form
> > data, convert it first then validate, and a bad
> validation for a currency
> > separator would say in the persons language "you
> are missing a currency
> > separator", send back the original value that was
> copied along with the
> > error message in the persons language
> > 
> > ----- Original Message -----
> > From: "Ted Husted" <hu...@apache.org>
> > To: <st...@jakarta.apache.org>
> > Sent: Monday, June 04, 2001 8:54 AM
> > Subject: Re: Client/Server Side Validation for
> Struts 1.1
> > 
> > > Good points, Michael.
> > >
> > > Language is one thing, location is another, and
> right now Java i18n does
> > > seem to infer location from language.
> > >
> > > In practice, this says that if they choose
> country XX on a
> > > contact form, then they should get the
> validations for country XX,
> > > regardless of any global XX locale setting. Of
> course, the same
> > > mechanism
> > > could apply to any number of validations, where
> the selection on one
> > > field affects what is valid in another.
> > >
> > > My first inclination would be to provide a broad
> validation in the
> > > FormSet (no letters in a telephone field (*)),
> and then perform a more
> > > complete validation server-side by invoking a
> specific validator (if I
> > > have one) for country XX.
> > >
> > > Of course, it would also be cool to support
> dynamic controls, where if
> > > they chose a different location (or whatever) on
> the form, the runtime
> > > validations on other fields would also change.
> > >
> > > -Ted.
> > >
> > > (*) At least telephone numbers should be
> letter-free now. As a child
> > > in the US, our telephone number was expressed as
> EXPORT 29156, which
> > > resolved to 3929156. Apparently we could not be
> trusted to remember
> > > 7 numbers back then ;-)
> > >
> > > Michael Westbay wrote:
> > > >
> > > > Husted-san wrote:
> > > >
> > > > > The validation.xml supports creating
> FormSets for different locales.
> > > >
> > > > Wait a second.  You just said "locales" right?
>  Yet what are Java
> > locales
> > > > used for?  Language.
> > > >
> > > > I live in Japan, however, if I'm browsing in
> English, what kind of phone
> > > > number am I going to get?  Dose the web
> designer need to write a en_JP
> > > > locale?  How about Spanish speakers in
> California?
> > > >
> > > > The name "locale" has always bothered me with
> Java, because it tends to
> > be
> > > > used to define a language rather than a place.
>  Yes, there are en_UK and
> > > > en_US versions, but even those are for
> differences in language
> > expressions
> > > > more than location.
> > > >
> > > > Now, let's say that my wife, born in Mexico,
> raised in the U.S., and now
> > > > living in Japan, is surfing the Web in
> Spanish, and wants to send a
> > present
> > > > to a friend in Brazil.  She's asked to enter a
> zip code.  What "locale"
> > will
> > > > be presented to her?
> > > >
> > > > Perhaps I missed something somewhere along the
> line where "locale" was
> > > > differentiated from "language" resources. 
> It's probably just a
> > semantics
> > > > problem as you all have probably been thinking
> all along that the checks
> > are
> > > > to be done based on the country that the user
> enters in a form, not the
> > > > "locale" to which (s)he is surfing.  But
> that'll be something else that
> > one
> > > > must keep in mind when solidifying a spec.
> > > >
> > > > Sorry, but even though "locale" is probably
> the correct word here, it's
> > kind
> > > > of confusing in the context of i18n in Java.
> > > >
> > > > --
> > > > Michael Westbay
> > > > Work: Beacon-IT http://www.beacon-it.co.jp/
> > > > Home:          
> http://www.seaple.icc.ne.jp/~westbay
> > > > Commentary:    
> http://www.japanesebaseball.com/
> > >
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Re: Client/Server Side Validation for Struts 1.1

[Ted Husted <hu...@apache.org>]

I believe that would happen under the current model. The validate
servlet is keyed to the user's locale, and would returns the language
elements for that locale regardless of where the error originated. 

The validator servlet understands that the properties may have different
labels in different locales, but the programtic property name remains
the same. The property may be "nomme", but the label may be "name"  for
the EN locale.

Michael was pointing out that someone might select ES as their "locale",
since they speak Spanish, but may be living in California. So there
needs to be a distinction between language and location.

Jonathan Asbell wrote:
> 
> Just a question.  Why dont you look at resolving validations the same way we
> look resolving data in a database or parameter names?  That is you dont
> store the parameter names in i18n text, just the values.  You dont store the
> database columns as i18n column names, just the data. Maybe we could have a
> "Local converter" which sees what local you are using, knows that text will
> be entered in i18n, and converts the i18n form data into the default Local
> format, THEN validate.  What I'm saying is that we make a copy of the form
> data, convert it first then validate, and a bad validation for a currency
> separator would say in the persons language "you are missing a currency
> separator", send back the original value that was copied along with the
> error message in the persons language
> 
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Monday, June 04, 2001 8:54 AM
> Subject: Re: Client/Server Side Validation for Struts 1.1
> 
> > Good points, Michael.
> >
> > Language is one thing, location is another, and right now Java i18n does
> > seem to infer location from language.
> >
> > In practice, this says that if they choose country XX on a
> > contact form, then they should get the validations for country XX,
> > regardless of any global XX locale setting. Of course, the same
> > mechanism
> > could apply to any number of validations, where the selection on one
> > field affects what is valid in another.
> >
> > My first inclination would be to provide a broad validation in the
> > FormSet (no letters in a telephone field (*)), and then perform a more
> > complete validation server-side by invoking a specific validator (if I
> > have one) for country XX.
> >
> > Of course, it would also be cool to support dynamic controls, where if
> > they chose a different location (or whatever) on the form, the runtime
> > validations on other fields would also change.
> >
> > -Ted.
> >
> > (*) At least telephone numbers should be letter-free now. As a child
> > in the US, our telephone number was expressed as EXPORT 29156, which
> > resolved to 3929156. Apparently we could not be trusted to remember
> > 7 numbers back then ;-)
> >
> > Michael Westbay wrote:
> > >
> > > Husted-san wrote:
> > >
> > > > The validation.xml supports creating FormSets for different locales.
> > >
> > > Wait a second.  You just said "locales" right?  Yet what are Java
> locales
> > > used for?  Language.
> > >
> > > I live in Japan, however, if I'm browsing in English, what kind of phone
> > > number am I going to get?  Dose the web designer need to write a en_JP
> > > locale?  How about Spanish speakers in California?
> > >
> > > The name "locale" has always bothered me with Java, because it tends to
> be
> > > used to define a language rather than a place.  Yes, there are en_UK and
> > > en_US versions, but even those are for differences in language
> expressions
> > > more than location.
> > >
> > > Now, let's say that my wife, born in Mexico, raised in the U.S., and now
> > > living in Japan, is surfing the Web in Spanish, and wants to send a
> present
> > > to a friend in Brazil.  She's asked to enter a zip code.  What "locale"
> will
> > > be presented to her?
> > >
> > > Perhaps I missed something somewhere along the line where "locale" was
> > > differentiated from "language" resources.  It's probably just a
> semantics
> > > problem as you all have probably been thinking all along that the checks
> are
> > > to be done based on the country that the user enters in a form, not the
> > > "locale" to which (s)he is surfing.  But that'll be something else that
> one
> > > must keep in mind when solidifying a spec.
> > >
> > > Sorry, but even though "locale" is probably the correct word here, it's
> kind
> > > of confusing in the context of i18n in Java.
> > >
> > > --
> > > Michael Westbay
> > > Work: Beacon-IT http://www.beacon-it.co.jp/
> > > Home:           http://www.seaple.icc.ne.jp/~westbay
> > > Commentary:     http://www.japanesebaseball.com/
> >

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/

Re: Client/Server Side Validation for Struts 1.1

[Jonathan Asbell <ja...@i-2000.com>]

Just a question.  Why dont you look at resolving validations the same way we
look resolving data in a database or parameter names?  That is you dont
store the parameter names in i18n text, just the values.  You dont store the
database columns as i18n column names, just the data. Maybe we could have a
"Local converter" which sees what local you are using, knows that text will
be entered in i18n, and converts the i18n form data into the default Local
format, THEN validate.  What I'm saying is that we make a copy of the form
data, convert it first then validate, and a bad validation for a currency
separator would say in the persons language "you are missing a currency
separator", send back the original value that was copied along with the
error message in the persons language


----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Monday, June 04, 2001 8:54 AM
Subject: Re: Client/Server Side Validation for Struts 1.1


> Good points, Michael.
>
> Language is one thing, location is another, and right now Java i18n does
> seem to infer location from language.
>
> In practice, this says that if they choose country XX on a
> contact form, then they should get the validations for country XX,
> regardless of any global XX locale setting. Of course, the same
> mechanism
> could apply to any number of validations, where the selection on one
> field affects what is valid in another.
>
> My first inclination would be to provide a broad validation in the
> FormSet (no letters in a telephone field (*)), and then perform a more
> complete validation server-side by invoking a specific validator (if I
> have one) for country XX.
>
> Of course, it would also be cool to support dynamic controls, where if
> they chose a different location (or whatever) on the form, the runtime
> validations on other fields would also change.
>
> -Ted.
>
> (*) At least telephone numbers should be letter-free now. As a child
> in the US, our telephone number was expressed as EXPORT 29156, which
> resolved to 3929156. Apparently we could not be trusted to remember
> 7 numbers back then ;-)
>
> Michael Westbay wrote:
> >
> > Husted-san wrote:
> >
> > > The validation.xml supports creating FormSets for different locales.
> >
> > Wait a second.  You just said "locales" right?  Yet what are Java
locales
> > used for?  Language.
> >
> > I live in Japan, however, if I'm browsing in English, what kind of phone
> > number am I going to get?  Dose the web designer need to write a en_JP
> > locale?  How about Spanish speakers in California?
> >
> > The name "locale" has always bothered me with Java, because it tends to
be
> > used to define a language rather than a place.  Yes, there are en_UK and
> > en_US versions, but even those are for differences in language
expressions
> > more than location.
> >
> > Now, let's say that my wife, born in Mexico, raised in the U.S., and now
> > living in Japan, is surfing the Web in Spanish, and wants to send a
present
> > to a friend in Brazil.  She's asked to enter a zip code.  What "locale"
will
> > be presented to her?
> >
> > Perhaps I missed something somewhere along the line where "locale" was
> > differentiated from "language" resources.  It's probably just a
semantics
> > problem as you all have probably been thinking all along that the checks
are
> > to be done based on the country that the user enters in a form, not the
> > "locale" to which (s)he is surfing.  But that'll be something else that
one
> > must keep in mind when solidifying a spec.
> >
> > Sorry, but even though "locale" is probably the correct word here, it's
kind
> > of confusing in the context of i18n in Java.
> >
> > --
> > Michael Westbay
> > Work: Beacon-IT http://www.beacon-it.co.jp/
> > Home:           http://www.seaple.icc.ne.jp/~westbay
> > Commentary:     http://www.japanesebaseball.com/
>

Re: Client/Server Side Validation for Struts 1.1

[Ted Husted <hu...@apache.org>]

Good points, Michael. 

Language is one thing, location is another, and right now Java i18n does
seem to infer location from language. 

In practice, this says that if they choose country XX on a
contact form, then they should get the validations for country XX,
regardless of any global XX locale setting. Of course, the same
mechanism
could apply to any number of validations, where the selection on one
field affects what is valid in another. 

My first inclination would be to provide a broad validation in the
FormSet (no letters in a telephone field (*)), and then perform a more
complete validation server-side by invoking a specific validator (if I
have one) for country XX. 

Of course, it would also be cool to support dynamic controls, where if
they chose a different location (or whatever) on the form, the runtime
validations on other fields would also change. 

-Ted.

(*) At least telephone numbers should be letter-free now. As a child 
in the US, our telephone number was expressed as EXPORT 29156, which 
resolved to 3929156. Apparently we could not be trusted to remember 
7 numbers back then ;-)

Michael Westbay wrote:
> 
> Husted-san wrote:
> 
> > The validation.xml supports creating FormSets for different locales.
> 
> Wait a second.  You just said "locales" right?  Yet what are Java locales
> used for?  Language.
> 
> I live in Japan, however, if I'm browsing in English, what kind of phone
> number am I going to get?  Dose the web designer need to write a en_JP
> locale?  How about Spanish speakers in California?
> 
> The name "locale" has always bothered me with Java, because it tends to be
> used to define a language rather than a place.  Yes, there are en_UK and
> en_US versions, but even those are for differences in language expressions
> more than location.
> 
> Now, let's say that my wife, born in Mexico, raised in the U.S., and now
> living in Japan, is surfing the Web in Spanish, and wants to send a present
> to a friend in Brazil.  She's asked to enter a zip code.  What "locale" will
> be presented to her?
> 
> Perhaps I missed something somewhere along the line where "locale" was
> differentiated from "language" resources.  It's probably just a semantics
> problem as you all have probably been thinking all along that the checks are
> to be done based on the country that the user enters in a form, not the
> "locale" to which (s)he is surfing.  But that'll be something else that one
> must keep in mind when solidifying a spec.
> 
> Sorry, but even though "locale" is probably the correct word here, it's kind
> of confusing in the context of i18n in Java.
> 
> --
> Michael Westbay
> Work: Beacon-IT http://www.beacon-it.co.jp/
> Home:           http://www.seaple.icc.ne.jp/~westbay
> Commentary:     http://www.japanesebaseball.com/

Re: Client/Server Side Validation for Struts 1.1

[Michael Westbay <we...@seaple.icc.ne.jp>]

Husted-san wrote:

> The validation.xml supports creating FormSets for different locales.

Wait a second.  You just said "locales" right?  Yet what are Java locales 
used for?  Language.

I live in Japan, however, if I'm browsing in English, what kind of phone 
number am I going to get?  Dose the web designer need to write a en_JP 
locale?  How about Spanish speakers in California?

The name "locale" has always bothered me with Java, because it tends to be 
used to define a language rather than a place.  Yes, there are en_UK and 
en_US versions, but even those are for differences in language expressions 
more than location.

Now, let's say that my wife, born in Mexico, raised in the U.S., and now 
living in Japan, is surfing the Web in Spanish, and wants to send a present 
to a friend in Brazil.  She's asked to enter a zip code.  What "locale" will 
be presented to her?

Perhaps I missed something somewhere along the line where "locale" was 
differentiated from "language" resources.  It's probably just a semantics 
problem as you all have probably been thinking all along that the checks are 
to be done based on the country that the user enters in a form, not the 
"locale" to which (s)he is surfing.  But that'll be something else that one 
must keep in mind when solidifying a spec.

Sorry, but even though "locale" is probably the correct word here, it's kind 
of confusing in the context of i18n in Java.

-- 
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home:           http://www.seaple.icc.ne.jp/~westbay
Commentary:     http://www.japanesebaseball.com/

Re: Client/Server Side Validation for Struts 1.1

[Ted Husted <hu...@apache.org>]

The validation.xml supports creating FormSets for different locales. The
language used to identify the field for JavaScript validation is also
defined here. I don't think you would need to change anything in the
code, any more than you would if this were coming from the Struts
message resource. The core idea being that language editors could make
all the changes within the XML file without touching the code.

I'm not sure how coding validations in the tags would work, unless
everything can be done within the field's event handler. In any case, I
believe that client-side validation have to be the primary requirement,
with JavaScript as a standard option. Which implies that the validations
need to be coded where the tags and other components can all see them.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/

Jim Richards wrote:
> 
> >  Here is an excerpt of the validation.xml file (I've
> >attached the full version).  The xml file lets you
> >define your validation rules, define global constants,
> >locale constants, and a formset has country, language,
> >and variant just like locale.
> 
> My reading of the validation.xml means that form fields
> become fixed, and non-changeable by the code. Which is
> not something that I prefer. I already have code that
> generates forms based on collections that I give it, and
> so something like this just wouldn't work. I'd prefer the
> validation to be in the struts <html:XXX/> tags.
> 
> --

Re: Client/Server Side Validation for Struts 1.1

[Jim Richards <gr...@cyber4.org>]

>  Here is an excerpt of the validation.xml file (I've
>attached the full version).  The xml file lets you
>define your validation rules, define global constants,
>locale constants, and a formset has country, language,
>and variant just like locale.  

My reading of the validation.xml means that form fields
become fixed, and non-changeable by the code. Which is
not something that I prefer. I already have code that 
generates forms based on collections that I give it, and
so something like this just wouldn't work. I'd prefer the
validation to be in the struts <html:XXX/> tags.


--
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

Re: Client/Server Side Validation for Struts 1.1

[David Winterfeldt <dw...@yahoo.com>]

The validation framework can handle different locales.
  Here is an excerpt of the validation.xml file (I've
attached the full version).  The xml file lets you
define your validation rules, define global constants,
locale constants, and a formset has country, language,
and variant just like locale.  If you don't specify
any of these, it will use the default locale.  You can
pass in variables with each locale, override the
default error message (message resource key), and have
parameters for the error message.  The global constant
can be overridden by a locale level constant.  So some
basic constants could be made for the most commonly
used locales or we could leave it up to the user and
just have examples.

<form-validation>
   <global>
      <constant name="zipPostal" value="^\d{5}\d*$" />
   </global>

   <formset>
      <constant name="zipPostal"
value="^\d{5}(-\d{4})?$" />
      
      <form    name="profileForm">
         <field    property="firstName"
         	   depends="required">
         	     <arg0
key="profileForm.firstName.displayname"/>
         </field>
         <field    property="zipPostal"
         	   depends="required,mask">
         	     <var name="mask" value="${zipPostal}"/>
         	     <msg name="mask"
key="profileForm.zipPostal.maskmsg"/>
         	     <arg0
key="profileForm.zipPostal.displayname"/>
         </field>
      </form>
   </formset>
   <formset language="fr" country="CA">
      <constant name="zip" value="^\d{5}(-\d{4})?$" />
      
      <form    name="profileForm">
         <field    property="firstName"
         	   depends="required">
         	     <arg0
key="profileForm.firstName.displayname"/>
         </field>
         <field    property="zipPostal"
         	   depends="required,mask">
         	     <var name="mask" value="${zipPostal}"/>
         	     <msg name="mask"
key="profileForm.zipPostal.maskmsg"/>
         	     <arg0
key="profileForm.zipPostal.displayname"/>
         </field>
      </form>
   </formset>
   
</form-validation>

Everything is online at my site if you want to look at
it.  The source, documentation, javadocs, and example
webapps are all available.

David Winterfeldt
http://home.earthlink.net/~dwinterfeldt

--- Michael Westbay <we...@seaple.icc.ne.jp> wrote:
> Richards-san wrote:
> 
> > >[...] 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.
> 
> I've used a number of such pages where I was unable
> to enter a valid phone 
> numbers and/or zip code due to such server-side
> checks.
> 
> > Things to note like this, in Australia we call
> them postcode, and have four
> > digits, in England they have letters and numbers.
> 
> And in Japan it's ###, ###-##, or ###-####.  While
> the 3-4 version is the 
> "official" one now, the others get the mail there
> still.  It's like just 
> using the 5-digit version in the U.S.
> 
> > We have 8 digit local
> > phone numbers (everywhere else has 6 or 7 I think
> and a 3 digit area code).
> 
> This is a tough one in Japan.  The area code always
> begins with 0 (unless 
> calling form outside of Japan) and may have 1,2, or
> 3 digits afterword.  The 
> next part could be 2, 3, or 4 digits depending on
> the size of the "area."  
> Then the last part is always 4 digits.  And, no,
> they don't always add up to 
> the same number of digits overall.  I think that
> keitai (cellular) phones are 
> all now 12 digits, with a given 4 digit "area code"
> given to each service 
> provider.  (Don't quote me on that one, though, as
> I'm still holding out on 
> being on call 7/24, so don't quite know all the
> facts.)
> 
> Also, there was something about currency mentioned. 
> When localizing for 
> currency, wouldn't some sort of logic have to be
> added to convert from a base 
> currency to the one of the locale?  Geneally, when I
> purchase something over 
> the Internet from a foreign country, it's in the
> currency of that country.  
> So I don't understand why this would be a feature of
> the presentation section 
> and not be part of the back-end logic (separate from
> Struts).  I think I 
> would need an example before I could comment any
> further on the merrit of 
> this one.
> 
> -- 
> Michael Westbay
> Work: Beacon-IT http://www.beacon-it.co.jp/
> Home:           http://www.seaple.icc.ne.jp/~westbay
> Commentary:     http://www.japanesebaseball.com/


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Re: Client/Server Side Validation for Struts 1.1

[Michael Westbay <we...@seaple.icc.ne.jp>]

Richards-san wrote:

> >[...] 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.

I've used a number of such pages where I was unable to enter a valid phone 
numbers and/or zip code due to such server-side checks.

> Things to note like this, in Australia we call them postcode, and have four
> digits, in England they have letters and numbers.

And in Japan it's ###, ###-##, or ###-####.  While the 3-4 version is the 
"official" one now, the others get the mail there still.  It's like just 
using the 5-digit version in the U.S.

> We have 8 digit local
> phone numbers (everywhere else has 6 or 7 I think and a 3 digit area code).

This is a tough one in Japan.  The area code always begins with 0 (unless 
calling form outside of Japan) and may have 1,2, or 3 digits afterword.  The 
next part could be 2, 3, or 4 digits depending on the size of the "area."  
Then the last part is always 4 digits.  And, no, they don't always add up to 
the same number of digits overall.  I think that keitai (cellular) phones are 
all now 12 digits, with a given 4 digit "area code" given to each service 
provider.  (Don't quote me on that one, though, as I'm still holding out on 
being on call 7/24, so don't quite know all the facts.)

Also, there was something about currency mentioned.  When localizing for 
currency, wouldn't some sort of logic have to be added to convert from a base 
currency to the one of the locale?  Geneally, when I purchase something over 
the Internet from a foreign country, it's in the currency of that country.  
So I don't understand why this would be a feature of the presentation section 
and not be part of the back-end logic (separate from Struts).  I think I 
would need an example before I could comment any further on the merrit of 
this one.

-- 
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home:           http://www.seaple.icc.ne.jp/~westbay
Commentary:     http://www.japanesebaseball.com/

Re: Client/Server Side Validation for Struts 1.1

[Andrew Harris <an...@netcomuk.co.uk>]

Regarding formatting/validation of money, there is one aspect 
which I omitted to mention earlier, namely in some countries it is 
necessary to support multiple currencies, such as DM and euro in 
Germany. Although there is a distinct locale each for DM and euro, 
there may be a reason to display both on the same page. Also 
some financial applications may require a variety of different 
currencies on the same page; for example you may need to 
display US$ for a German user.

The point is that the user's locale may not be sufficient to 
determine the currency, and hence formatting. 

Moreover, the formatting could depend on both the currency and 
the user's locale, for example the user locale could determine the 
decimal point convention and thousands separator convention ("," 
or "."). Java itself does not provide support for formatting dependent 
on both user locale and currency, so if this is needed it would have 
to be hand made. Other than this, you can go a long way with the 
support which Java has built in for currency.

--
Andrew Harris			
andrewsh@netcomuk.co.uk

Re: Client/Server Side Validation for Struts 1.1

[Jim Richards <gr...@cyber4.org>]

>> 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

Re: Client/Server Side Validation for Struts 1.1

[Ted Husted <hu...@apache.org>]

David Winterfeldt wrote:
> I think it would be good to get a list together of all
> the basic validations we would want to do.  I normally
> want to do validations based on the database field the
> bean field corresponds to and basic things like phone
> numbers, zip codes, etc.  Is the date validation you
> made i18n?

My date validation was just for the credit card expry date (after
today), but we would obviously want something that was i18n and could
adjust for the user's locale.

Can anyone suggest an existing package, for any platform, that covers
this ground? We might be able to use it for a punch list and to model
the high-level requirements.

I wandered around in the Barracuda source last night, and they have a
nice object for handling conversions between first class types
(org.enhydra.barracuda.core.forms.FormElement), and a base validator
object (DefaultFormValidator) for plugging in whatever validators you
need.

Offhand, I would lean toward keeping our base objects as close to
Barracuda's as we can, and look toward another mature product for other
coding conventions, like the meta-language for expressing the target 
format (the "(###) ###-####)" part ). 
 
> I like the idea of a transformation package a lot.  I
> think it would be good if it were separate.  I've read
> the other thread.  If all the fields for a form were
> specified in the XML file even if they didn't need to
> be validated, the "XML --> ActionForm Code Generator"
> on the To Do list could use the validation.xml to
> generate the ActionForm (of course it would have to be
> smart enough to handle nested properties).  

Speaking of code generation, here's another idea. 

What about a stub code generator that started with the model/application
properties. Then we could also generate a SQL DDL, along with the
ActionForm bean and several other core objects. 

So, we would input (via XML or a Web interface) the property/column
name, Java type, [JDBC type,] and whether the property was a database
column, used on a form, used on a read-only view, or used on a list
(master/detail pattern). 

Depending on the choices, the code generator could then output a Java
SQL DDL (for creating the database), a plain JavaBean, an object value
bean (non-mutable, bulk constructor), Struts HTML form, Struts HTML page
(read only via bean:write), Struts HTML result page (multiple rows,
links to an Action), Struts ActionForm bean (or ValidatorForm bean),
Struts data access Action, data access Result bean, and relevant
sections of the Struts configuration file (and validation.xml file).

The skeleton for some of these objects could come from the Strut by
Strut article (just updated, if anyone wants to peak). 

For this to be most useful, it would have to handle the data conversions
and transformations, which again leads back to the base
transformation/validation package. 

If we were clever, we'd write this code generator so that it could be
used in other environments. Something that just generated a Java
SQL DDL, JavaBean, value object bean, and HTML form page, would also
seem generally useful. 

Perhaps we should join the two, and look at one package called say
"tonic", with a base transformation/validation object, and a XML-to-Java
object generator that would use the base t/v object to work its magic.

Which again would be good Commons fodder.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/

Re: Client/Server Side Validation for Struts 1.1

["Anders K. Olsen" <ak...@post4.tele.dk>]

----- Original Message ----- 
From: "David Winterfeldt" <dw...@yahoo.com>
To: <st...@jakarta.apache.org>
Sent: Sunday, June 03, 2001 8:57 AM
Subject: Re: Client/Server Side Validation for Struts 1.1


> 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.

Best wishes

Anders.

Re: Client/Server Side Validation for Struts 1.1

[David Winterfeldt <dw...@yahoo.com>]

--- Ted Husted <hu...@apache.org> wrote:
> David Winterfeldt wrote:
> > Nic Hobbs and I have both volunteered for the
> Standard
> > (Server Side) Validations and Ted Husted, Nic
> Hobbs,
> > Spencer Smith and I have volunteered for the
> Client
> > Validations (JavaScript).  Ted has been using a
> > validation framework I've done on a project 
> 
> I'm real happy with David's framework and would +1
> it as Struts 1.1
> component (I'm already touting it as a standard
> option in the new Strut
> by Strut piece.)
thanks
> 
> One thing I had to do myself was to add some
> validations and
> transformations that were outside the scope of
> regular expressions. For
> example, forcing a string property to uppercase,
> validating the general
> format of a credit card number, checking that a date
> is current. Of
> course, I deployed these in both Javascript and then
> client-side as part
> of the ActionForm validation. 
I think it would be good to get a list together of all
the basic validations we would want to do.  I normally
want to do validations based on the database field the
bean field corresponds to and basic things like phone
numbers, zip codes, etc.  Is the date validation you
made i18n?

> My only thought would be whether we want
> to provide support for extending the package for
> custom, non-Regex
> validations, and perhaps transformations. If so,
> that leads to the idea
> of whether we might want a seperate helper package
> that could handle the
> grunt-work and plug into the Validator (see also
> "Proposed feature: Bean
> propertytransformations").
> 
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.

I like the idea of a transformation package a lot.  I
think it would be good if it were separate.  I've read
the other thread.  If all the fields for a form were
specified in the XML file even if they didn't need to
be validated, the "XML --> ActionForm Code Generator"
on the To Do list could use the validation.xml to
generate the ActionForm (of course it would have to be
smart enough to handle nested properties).  We could
also have a type attribute for a field that could be
set to defined types like byte, int, etc.  It would be
nice then if there was a matching validation to make
sure it was a byte and then the transformation to
convert it to a byte.  I think it is good to keep the
ActionForm and the bean with get/set handling
something other than String separate.  There could be
a mapping between the ActionForm and the other bean in
the xml file.

David

> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Re: Client/Server Side Validation for Struts 1.1

[Ted Husted <hu...@apache.org>]

David Winterfeldt wrote:
> Nic Hobbs and I have both volunteered for the Standard
> (Server Side) Validations and Ted Husted, Nic Hobbs,
> Spencer Smith and I have volunteered for the Client
> Validations (JavaScript).  Ted has been using a
> validation framework I've done on a project 

I'm real happy with David's framework and would +1 it as Struts 1.1
component (I'm already touting it as a standard option in the new Strut
by Strut piece.)

One thing I had to do myself was to add some validations and
transformations that were outside the scope of regular expressions. For
example, forcing a string property to uppercase, validating the general
format of a credit card number, checking that a date is current. Of
course, I deployed these in both Javascript and then client-side as part
of the ActionForm validation. My only thought would be whether we want
to provide support for extending the package for custom, non-Regex
validations, and perhaps transformations. If so, that leads to the idea
of whether we might want a seperate helper package that could handle the
grunt-work and plug into the Validator (see also "Proposed feature: Bean
propertytransformations").

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/