--- On Fri, 12/12/08, David E Jones <[email protected]> wrote:
> From: David E Jones <[email protected]> > Subject: Re: LocalizedMap.java - Do we really need it? > To: [email protected] > Date: Friday, December 12, 2008, 7:50 PM > On Dec 12, 2008, at 5:42 PM, Adrian Crum wrote: > > > Thinking about this more... > > > > Localizing data is a presentation layer issue. The > entity engine should be concerned with storing and > retrieving data - not localization issues. It's > unfortunate that presentation layer code has made its way > into the entity engine. > > How could i18n/l10n be a presentation layer only issue? I > suppose if your app only had a presentation layer then that > would be true, but logic and data layers are generally used > for i18n functionality, and often need to be aware of the > user's Locale in order to preform and respond properly. > > Are you saying that we should remove all Locale awareness > from the service engine and the entity engine? No, just the entity engine. > > From my perspective, a better way to implement entity > engine localization would be through presentation layer > decorators for the entity engine classes. > > A decorator for a lower level class? That sounds buzzword > friendly, but using more literal language, what do you mean? > Do you mean something like that ProductContentWrapper (that > should really be turned into set of services, IMO... and yes > I'm the guilty party that wrote it) which is really just > a utility class to hide the complexity of the underlying > data model, which among other things supports localization? It would be a simple change to make - since there are only a couple of methods in the entity engine that would be affected. So, let's say we take the LocalizedMap code out of the entity engine, then in ScreenRenderer.populateBasicContext change context.put("delegator", delegator); to context.put("delegator", new LocalizedDelegator(delegator, context)); LocalizedDelegator would have similar decorators for the entity engine classes that need them - like GenericEntity. In the end, you have classes that behave the same as the decorated classes, only they hold a reference to the rendering context so they can do localization conversions when needed. Tah-dah! From that point on, all calls to GenericEntity.get() will be localized - without the need for a Locale argument. The same concept could be applied to the service engine. With something like that in place, we don't need to develop kludges to get LocalizedMap to work with third party libraries that only know about a plain Map. Integration efforts like the UEL will be much easier. By the way "decorator" is not a buzzword, it's a design pattern. Sun uses it a lot in the java.io package. -Adrian
