Obviously, keeping everything in the bean would be simpler. But I have two
problems with that approach:
1) It complicates localization. If I keep everything in the properties file
I18N is much cleaner.
2) This is just one example of places where database-resident information is
going to be presented to the user. You could also imagine having the same
problem with product names, user roles and a whole whack of other things.
Sooner or later, I'm going to have to tackle bean-based indexing. Might as
well figure it out now.
Jefficus
----- Original Message -----
From: "Rick Reumann" <[EMAIL PROTECTED]>
>
> I haven't had to tackle this issue, but I was wondering if maybe a
> better approach would be to let the DB handle the proper language names
> as well for the different codes. Then based on whatever locale being
> used your query would make sure to select the appropriate country codes
> and names. In another words I was thinking you'd have a typical bean:
>
> Country {
> String id; //CA
> String description; //Canada
> }
>
> But your business logic that would return your Collection of these might
> take a Locale as a parameter so that it would return the Collection of
> Country objects populated with the proper language for the description
> field.
>
> Not sure if this is the best approach to take or not so I'm interested
> to hear what you finally go with.
>
> --
> Rick
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
