--- On Sun, 12/14/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: Sunday, December 14, 2008, 2:09 AM
> 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.
I have no doubt there are things I overlooked - because I'm just presenting a
concept, not a detailed implementation strategy. I'm sure the issues you
brought up could be resolved if I looked into them further.
My point was that the existence of LocalizedMap makes third party library
integration harder than it should be. FlexibleMapAccessor.java is a good
example - almost 10% of its code is a kludge to accommodate LocalizedMap.
Anyways, I took care of it - the LocalizedMap has been accommodated. Time to
move on to other things...
-Adrian
