So you want to take static model data (e.g. a product type code) and,
instead of looking up a localized display name for that type code in the
JSP, do the lookup in the action form? [Jack: he's not talking about
localizing natural language data entered by the user, that's clearly not
feasible!]
You certainly could do that. You'd have to pass the appropriate locale into
the form bean in the action you use to pre-populate data for the JSP or at
the start of the JSP itself. The trade off is slightly simpler JSP markup
(e.g. <bean:write value="myForm.productTypeDisplayText"/> instead of
<bean:message key="myForm.productType" fmt="..."/> vs. a loss of
flexibility. For example, if you wanted to tweak the display format, you'd
have to recompile your form bean rather than just edit the JSP.
On the other hand, your form bean and/or action already needs to be
locale-aware when parsing data entered by the user (think about entering
dates, for example: you have to know how to parse the date string according
to the user's locale). Whilst you can control locale specific formatting of
output data in the JSP, there's no way to do so for input data. So keeping
both in the same place (e.g. the form bean) is probably a good idea.
I'd probably make sure the option was there to override formatting in the
JSP just in case (e.g. by having both getProductType() and
getProductTypeDisplayText() on the form bean), though. And I may not bother
for uni-directional data (i.e. data that only needs to be localized for
display, with no locale-to-canonical-representation processing in the other
direction). So for the product code example I probably wouldn't put
localization code in the action form, but I would for something like an
editable date property.
L.
Joe Hertz wrote:
It seems logical to do, but steadfastly avoided. So I'm wondering if this is
a bad idea or not-
Example:
You have a series of i18N'd CRUD screens. On one of them, you allow the user
to retrieve some data, edit it, and save it back.
On this type of screen, it really makes life easier if you pass the data
into the screen on an instance of the FormBean that is going to be submitted
back to you. The JSP properties will display it as is.
This has gotten me in the habit of using FormBeans for display purposes.
So now I'm thinking, why not add i18N functionality into the FormBean? It
seems to me to be a pretty good place to do it.
If a field contains a code, you can copy that into the form into the
"widgetCode" property, confident that the getter for "widgetText" will
convert it for you to the right language.
But to do this, you need an ActionForm Object that can store a Locale and a
MessageResources bundle.
Is there any reason not to? (Form Scoping issues? etc)
TIA
-Joe
--
Laurie Harper
Open Source advocate, Java geek: http://www.holoweb.net/laurie
Founder, Zotech Software: http://www.zotechsoftware.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
