If the Transformation interface translates objects to and from
Strings, how is it different than PropertyEditors?
-will
Ron Smith writes:
> I like the idea of combining transformations with some validation
> logic. After all, you commonly validate the contents of a String by
> trying to tra
I like the idea of combining transformations with some validation
logic. After all, you commonly validate the contents of a String by
trying to transform it into some other data type.
I'm also interested in the discussions going on about client side
validation and locale/language specific validat
Hi,
While trying to port Cedric Dumoulin's Components library to the latest
(5/6/2001) Struts, I've found a few BeanUtils methods have vanished. In
particular:
BeanUtils.filter(value);
BeanUtils.getScalarProperty(bean, property);
Having a poke in the Struts source, it seems:
- the filter() met
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 mig
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. [...]
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
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
"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 l
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
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 p
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 zipco
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 l
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, an
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
d
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
Ted Husted wrote:
> Martin Cooper has submitted several useful patches to Struts, has been
+1, Firmly agreed!
Robert Leland [EMAIL PROTECTED]
804 N. Kenmore Street +01-703-525-3580
Arlington VA 22201
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 hav
Hello Ted,
+1
Monday, June 04, 2001, 4:52:37 PM, you wrote:
TH> Martin Cooper has submitted several useful patches to Struts, has been
TH> very active on the Mailing List for as long as many of us can remember,
TH> and has shown a deep understanding of using Struts in a production
TH> environme
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
Martin Cooper has submitted several useful patches to Struts, has been
very active on the Mailing List for as long as many of us can remember,
and has shown a deep understanding of using Struts in a production
environment. Martin has also volunteered to help clean up the remaining
issues for beta
21 matches
Mail list logo
