I still think it may be better to have one validation package and a bunch of
filter/transformers for each lnaguage and local you want to support. That
way the user can enter in data in the way he/she is accostomed, and we
developers who are aware of such differences can convert the users format
into our own which we use to process and validate. When you want to add a
language and or local, just make a filter/converter for it, and use the
exact same validation package without having to add to it for each
local/language.
Would love to hear any comment on this.
cheers
Jonathan
----- 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 --------------------
>
> 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
> 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" <[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 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" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > 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.
> > >
> >
>
>
>
> --------------------- End of message text --------------------
>
> The principal place of business of PricewaterhouseCoopers and its
associate
> partnerships is 1 Embankment Place, London WC2N 6NN where lists of the
> partners' names are available for inspection. All partners in the
associate
> partnerships are authorised to conduct business as agents of, and all
> contracts for services to clients are with, PricewaterhouseCoopers. The UK
> firm of PricewaterhouseCoopers is authorised by the Institute of Chartered
> Accountants in England and Wales to carry on investment business.
> PricewaterhouseCoopers is a member of the world-wide
> PricewaterhouseCoopers organisation.
> ----------------------------------------------------------------
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you
received
> this in error, please contact the sender and delete the material from any
> computer.
>
