I agree with Nick that a lot of these scenarios can't
be known until the user enters the country that the
address info belongs to. What if someone in Britain
is sending a gift to someone in France? What if your
home address is in one country and you work in another
so you put down your business phone for contact info
and it won't let you? I don't like forms that reject
what I'm entering. I think in the US you can probably
be specific, but in Europe I always thought it would
be easier to have vary loose validation rather than
trying to figure out all of the possible combinations
of a user's locale, the country they entered, etc.
This is an excerpt from an earlier e-mail.
Ted Husted wrote:
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>
This would be very easy to do. Maybe when we make
formatting tags they could access this info and then
you could specify whether or not to use the server's
default locale (ex: currency display), the client's
locale, or pass in your own format.
Nothing for the locale could default to either server
or client. We could decide what makes the most sense
or it could be configurable when you setup the default
formats.
<html:format name="tel">
5135551212
</html:format>
I think that it might be good to stick to upper case
representations of countries like the java.util.Locale
object returns when you call getCountry().
<html:format name="tel" locale="AU">
5135551212
</html:format>
<html:format pattern="(###) ###-####">
5135551212
</html:format>
David
--- [EMAIL PROTECTED] wrote:
>
> Memo from Nic Hobbs of PricewaterhouseCoopers
>
> -------------------- Start of message text
> --------------------
>
> Firstly let me apologise for my lack of
> communication recently - we have
> had some deadlines on our project that have kept me
> busy. I have been
> lurking and listening to the discussions though, but
> find I often am too
> late to reply to things - when I get around to it
> someone has already
> answered the question! Especially with most of you
> being in a different
> time zone ;)
>
> Anyway, on to the point. I agree that we need to
> distinguish between the
> view and the model here. It has long been a concern
> of mine, coming from a
> languages and linguistics background originally
> that, especially in the
> java world, locales are too simplified for many of
> the reasons that have
> been mooted here.
>
> However, I don't think we need to complicate things
> too much. William is
> right by saying that, in the example of currencies,
> the calcualation of the
> value in different currencies is the responsilibity
> of the business logic,
> whether by a feed or a static table or however. The
> responsibility of the
> view is just to render it with the correct currency
> format.
>
> This however, doesn't answer the questions of our
> now well mooted Spanish
> speaking, mexican ex-pat, californian trying to buy
> in Brazil (phew...). I
> would like to point something out on this score
> though. The chances are
> that if our mexican friend is accessing a brazilian
> website the values they
> will be seeing will be in the currency of that
> country rather than in their
> own. So several things: a) we cannot just use their
> local to render the
> values as this will list them in US dollars and b)
> for most sites the
> closest they get to showing currency conversions is
> a link to an external
> site that does this sort of thing, so we don't have
> to worry about
> conversion c) we can only really validate an address
> against a PAF (an
> address/postcode file in the UK) or its equivalent.
>
> This leaves us with an interesting scenario. We have
> found that the locale
> needed to render the values is in fact that of the
> server rather than the
> client (which is not the current struts approach)
> and that in order for the
> customer to complete their order they will need to
> enter in an address
> which is in their locale and not the server's (ie
> potentially different
> postcodes (sorry I'm european!) and 'phone numbers).
>
> So how do we handle this? The display of values that
> we have control over
> is pretty straight forward as we can control the
> server locales ourselves
> and render them on the screen accordingly, although
> not using the automatic
> recognition of locale that struts supports. This is
> also true of multiple
> currencies such as the example of euros and DM in
> Germany. This is in fact
> something we are dealing with on our project for a
> financial client at the
> moment.
>
> The others are more of a problem. However, again
> there are several
> strategies that we can adopt as far as I see it. The
> first is that in the
> scenario above there may well be a limit to where
> the company is prepared
> to export to and therefore they only need to support
> the locales they want
> to. The second is that we could support minor
> validation on the client side
> (ie a phone number is only numbers and brackets or
> something similar) and
> do the full validation on the server side based on
> subclasses for each
> locale we want to support. In this scenario we have
> one form for all
> locales (used loosely) but check the format on the
> server for a specific
> locale. However, we still have problems even here.
> Take for instance the
> Spanish name. US and UK names tend to be along the
> lines of Fred Smith.
> Spanish names include both the mother's and father's
> surnames i.e. Fred
> Jones Smith (well the spanish equivalent anyway ;)
> How can we cope with
> this on one form? Aren't these business decisions to
> be made rather than
> one's for the framework?
>
> I think we need to concentrate IMHO on several
> things - the first is that
> we are trying to provide a framework for people to
> do their validations in
> easily rather than to provide an application that
> validates every
> conceivable option. The second is that not all
> validations can be
> represented in regular expressions ( this is not to
> take anything from
> david's validation framework, which although I have
> not used myself looks
> good as a basis, as Ted suggested). The third is
> that we should provide for
> 'cross-field' validations - if the user selects this
> option they should
> only fill in these fields etc. And the fourth, the
> big one is, i18n.
>
> So where do I suggest we go from here? Well that is
> a good question. Part
> of me thinks we should concentrate on 1-3 above to
> provide a framework for
> people to use for validation however they want to;
> Part of me knows, from
> experience, you can't bolt on i18n after the fact.
>
> So what I can suggest so far is to concentrate on
> getting a framework
> together which doesn't preclude us from doing
> anything fancy with i18n but
> that doesn't have it as it's only initial goal. To a
> certain extent, and I
> know this will cause some discussion but.... coming
> back to how this mail
> started, the use of the validation in an
> internationalised way is part of
> the business logic - deciding which locales or
> locations you will or will
> not send your products to, or validate cannot be
> determined automagically
> as we have seen from the scenarios above.
>
> Incidently, I like the idea of encapsulating a
> certain amount of validation
> logic in 'widgets', like the taglibs suggested:
> <html:date/>, <html:name/>
> 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 data
> dictionary. Or perhaps <html:input class="name" ...
> /> etc. or something
> similar...
>
> Now I've ranted for a good page and probably not
> added anything valid to
> the discussion, I'll sign off! ;)
>
> Nic
>
> PS Sorry for the length - I know we are all busy!
>
>
>
>
>
>
> William Jaynes <[EMAIL PROTECTED]> on 05/06/2001
> 13:36:53
>
> Please respond to [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> cc:
>
>
> Subject: Re: Client/Server Side Validation for
> Struts 1.1
>
>
> Remember... separation of view from model. The act
> of displaying an
> amount in a particular currency format is separate
> from determining what
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
