AIL PROTECTED]>
Subject: Re: Client/Server Side
Validation for Struts 1.1
ristian Cryder" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Jonathan
> Asbell" <[EMAIL PROTECTED]>
> Sent: Tuesday, June 19, 2001 11:12 AM
> Subject: RE: Client/Server Side Validation for
> Struts 1.1
>
>
> > Hi Jonathan,
OUR FORMAT. Therfore the
filter must know about "@" characters etc.
- Original Message -
From: "Christian Cryder" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Jonathan Asbell" <[EMAIL PROTECTED]>
Sent: Tuesday, June 19, 2001 11:12 AM
Subject: RE: Cl
ities
>
> What do you think?
>
> - Original Message -
> From: "David Winterfeldt" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Jonathan Asbell"
> <[EMAIL PROTECTED]>
> Sent: Monday, June 18, 2001 11:01 PM
> Subject: Re: Client
uot; <[EMAIL PROTECTED]>
Sent: Monday, June 18, 2001 11:01 PM
Subject: Re: Client/Server Side Validation for Struts 1.1
> What do you mean by "converted into the format of the
> system"? Do you mean the object and not the String
> representation in the ActionForm? Or a
> situation as needed, and one central validation
> package.
>
> - Original Message -
> From: "David Winterfeldt" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, June 18, 2001 2:26 PM
> Subject: RE: Client/Server Side Validatio
situation as needed, and one central validation package.
- Original Message -
From: "David Winterfeldt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 18, 2001 2:26 PM
Subject: RE: Client/Server Side Validation for Struts 1.1
> I've still been
dation
> framework?
>
> Fr.
>
> -Original Message-----
> From: David Winterfeldt
> [mailto:[EMAIL PROTECTED]]
> Sent: 15 June 2001 14:31
> To: [EMAIL PROTECTED]
> Subject: RE: Client/Server Side Validation for
> Struts 1.1
>
>
> I just wanted to pu
tions for a validation framework?
Fr.
-Original Message-
From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
Sent: 15 June 2001 14:31
To: [EMAIL PROTECTED]
Subject: RE: Client/Server Side Validation for Struts 1.1
I just wanted to put this out there to see what people
think since I too
CTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 9:34 AM
Subject: Re: Client/Server Side Validation for Struts 1.1
> I've gotten down to a 15,000 foot view of Barracuda, and it looks like
> they are doing some nice work. All things remaining equal, I believe it
>
Sent: Friday, June 15, 2001 9:34 AM
Subject: Re: Client/Server Side Validation for Struts 1.1
> I've gotten down to a 15,000 foot view of Barracuda, and it looks like
> they are doing some nice work. All things remaining equal, I believe it
> would be better if our approaches were comp
I've gotten down to a 15,000 foot view of Barracuda, and it looks like
they are doing some nice work. All things remaining equal, I believe it
would be better if our approaches were compatible with Barracuda. For
example, if someone did want to do more with event processing, using as
much of Barra
ration with struts is just in two places:
> in a descendent from the
> ActionServlet, where we load the configuration file,
> and in a descendant
> from the ActionForm, where the validate method calls
> the mapper associated
> with the form and produces an ActionError for each
>
rom the ActionForm, where the validate method calls the mapper associated
with the form and produces an ActionError for each validation/transformation
failure.
Fr.
-Original Message-
From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
Sent: 14 June 2001 06:32
To: [EMAIL PROTECTED]
Subject: Re: Cl
have as much activity and it seems as though they are still working out some
larger bugs.
- Original Message -
From: "David Winterfeldt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 14, 2001 12:31 AM
Subject: Re: Client/Server Side Validation for St
I just saw the type conversion thread going on in the
user list, but I've thought about this for a bit and
you mentioned possibly modeling or taking code from an
existing framework.
How closely have you looked at Barracuda Ted? Some of
what they do is interesting. I think we could make an
Act
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
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,
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2001 10:55 AM
Subject: Re: Client/Server Side Validation for Struts 1.1
>
> Memo from Nic Hobbs of PricewaterhouseCoopers
>
> Start of message text
I still have the feeling that we lack a decent foundation package to do
the grunt work of typecasting and String formatting, so that things like
a Validation servlet and something like a tag could share a common codebase.
We might want to start with something like this:
<
http://www.mail-arch
Asbell" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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 sam
a
> certain amount of validation
> logic in 'widgets', like the taglibs suggested:
> ,
> etc. providing we have some way of defining other
> than in code exactly what
> it means to be a 'name' and so on - I guess the idea
> of a sort of da
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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2001 7:40 AM
Subject: Re: Client/
Message -
From: "Jonathan Asbell" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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 s
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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2001 7:28 AM
Subject: Re: Client/Server Side
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 th
- Original Message -
From: "Michael Westbay" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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 a
We are developing here such validation framework. I've already posted a
message about this on 11 May, but I didn't get much reply yet. The problem
we are trying to solve here is to not only do a validation, but also convert
the form fields into objects, e.g. from a string to a date object, an
ope
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
mating for display should take into account
the locale.
Hal
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 04, 2001 12:13 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Client/Server Side Validation for Struts 1.1
>
>
> We'
--
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
> _
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:
>
>
itance with the Language being first, and
the Location being and overridable subclass.
- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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 l
t; copied along with the
> > error message in the persons language
> >
> > - Original Message -
> > From: "Ted Husted" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, June 04, 2001 8:54 AM
> > Subject: Re: Cli
lt;[EMAIL PROTECTED]>
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
was copied along with the
> error message in the persons language
>
> - Original Message -
> From: "Ted Husted" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, June 04, 2001 8:54 AM
> Subject: Re: Client/Server Side Validation for St
o: <[EMAIL PROTECTED]>
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 pract
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
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
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. Th
> 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 f
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 valida
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
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 du
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
>> 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 reme
- Original Message -
From: "David Winterfeldt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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 h
--- Ted Husted <[EMAIL PROTECTED]> 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
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
54 matches
Mail list logo
