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.
