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?
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?
-David
--- 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, 2:46 PM
How do you plan to support the Entity Engine (through
GenericEntity) feature of implicitly localized fields
(currently used for StatusItem, Enumeration, various
others)?
What FlexibleMapAccessor is doing with LocalizedMap is
seeing if the Map passed to it implements the interface, and
if so then when doing a "get" operation it will
pass in the locale.
The LocalizedMap interface was created and is implemented
by GenericEntity so that the FlexibleMapAccessor would not
have to know about the GenericEntity class itself (since
FlexibleMapAccessor is lower level and doesn't know
anything about the entity engine).
You can eliminate it, but please understand what it is
doing and implement that in a different way before doing so.
It would be a shame to lose this feature and break the
various things that depend on it.
-David
On Dec 12, 2008, at 3:21 PM, Adrian Crum wrote:
Just for fun, I eliminated the LocalizedMap interface
on my local copy and everything still works. The only
potential area affected would be the localized entity data -
and that works fine.
-Adrian
Adrian Crum wrote:
I'm having a problem integrating the Unified
Expression Language with the FlexibleMapAccessor class - due
to that class supporting the LocalizedMap interface. The
LocalizedMap interface is implemented in the MapStack class
and it is used in only one place - GenericEntity.
Here's the thing - I can't think of any
scenario where this kind of functionality would be needed.
Where in the framework do we ever construct a MapStack with
different elements for different locales? As far as I know,
each MapStack instance represents a single locale. Am I
wrong? If not, can we phase out LocalizedMap?
-Adrian
