On Dec 13, 2008, at 8:46 AM, Adrian Crum wrote:
--- 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.
My favorite definition of a buzzword as anything that's used so
commonly and in so many different circumstances that when someone uses
it you can never really be sure of what they mean, though mostly
people just assume that their interpretation of it is the one the
speaker meant. In other words, it's a barrier to effective
communication.
Anyway, wouldn't doing something like this result in needing a new
delegator instance for basically every request, and in some cases
multiple per request? Wouldn't this also lead to possible problems
where a general instance of the delegator is used instead of one that
is passed into the service call or ControlSerlvet request event or
what what? You mentioned the screen rendering, but more would really
have to be done, including processing of data coming in which might be
formatted according to some locale-based variant on the consistently
inconsistent standards in our funny world...
This would introduce something that we've tried to avoid a lot, and
that is "controller" objects (as in the model-view-controller pattern)
that are stateless and therefore inherently scalable with the context
needed for each operation passed into it. That makes things much
easier to understand, and therefore to maintain, along with generally
performing better and having less risk of non-thread-safe issues
coming up.
-David
