You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@hlmksw.com> on 2008/12/12 18:49:59 UTC
LocalizedMap.java - Do we really need it?
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
Re: LocalizedMap.java - Do we really need it?
Posted by David E Jones <da...@hotwaxmedia.com>.
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 <da...@hotwaxmedia.com>
> wrote:
>
>> From: David E Jones <da...@hotwaxmedia.com>
>> Subject: Re: LocalizedMap.java - Do we really need it?
>> To: dev@ofbiz.apache.org
>> 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
>
>
>
Re: LocalizedMap.java - Do we really need it?
Posted by Adrian Crum <ad...@yahoo.com>.
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.
>From my perspective, a better way to implement entity engine localization would be through presentation layer decorators for the entity engine classes.
-Adrian
--- On Fri, 12/12/08, David E Jones <da...@hotwaxmedia.com> wrote:
> From: David E Jones <da...@hotwaxmedia.com>
> Subject: Re: LocalizedMap.java - Do we really need it?
> To: dev@ofbiz.apache.org
> 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
Re: LocalizedMap.java - Do we really need it?
Posted by Adrian Crum <ad...@yahoo.com>.
Or maybe I'm missing something...
What I meant was localized fields were displayed fine (PartyManager Main for example).
I understand what you're saying - there is a chance that a GenericEntity (masquerading as a Map) could be in the Map passed to FlexibleMapAccessor and any get() calls on it would not be localized.
In that case, I'll leave the localized get() in FlexibleMapAccessor, but that method won't support the UEL.
Thanks for your input - that really helped clarify things.
-Adrian
--- On Fri, 12/12/08, David E Jones <da...@hotwaxmedia.com> wrote:
> From: David E Jones <da...@hotwaxmedia.com>
> Subject: Re: LocalizedMap.java - Do we really need it?
> To: dev@ofbiz.apache.org
> Date: Friday, December 12, 2008, 2:53 PM
> What do you mean by "still localized fields just
> fine"? Do you mean
> that somehow it managed to localize the field _without_ the
> Locale
> being passed in? Must be some sort of voodoo involved...
>
> -David
>
>
> On Dec 12, 2008, at 3:51 PM, Adrian Crum wrote:
>
> > I tested GenericEntity and it still localized fields
> just fine. I
> > will continue to look into it though. Thanks for the
> reply!
> >
> > -Adrian
> >
> >
> > --- On Fri, 12/12/08, David E Jones
> <da...@hotwaxmedia.com>
> > wrote:
> >
> >> From: David E Jones
> <da...@hotwaxmedia.com>
> >> Subject: Re: LocalizedMap.java - Do we really need
> it?
> >> To: dev@ofbiz.apache.org
> >> 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
> >
> >
> >
Re: LocalizedMap.java - Do we really need it?
Posted by David E Jones <da...@hotwaxmedia.com>.
What do you mean by "still localized fields just fine"? Do you mean
that somehow it managed to localize the field _without_ the Locale
being passed in? Must be some sort of voodoo involved...
-David
On Dec 12, 2008, at 3:51 PM, Adrian Crum wrote:
> I tested GenericEntity and it still localized fields just fine. I
> will continue to look into it though. Thanks for the reply!
>
> -Adrian
>
>
> --- On Fri, 12/12/08, David E Jones <da...@hotwaxmedia.com>
> wrote:
>
>> From: David E Jones <da...@hotwaxmedia.com>
>> Subject: Re: LocalizedMap.java - Do we really need it?
>> To: dev@ofbiz.apache.org
>> 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
>
>
>
Re: LocalizedMap.java - Do we really need it?
Posted by Adrian Crum <ad...@yahoo.com>.
I tested GenericEntity and it still localized fields just fine. I will continue to look into it though. Thanks for the reply!
-Adrian
--- On Fri, 12/12/08, David E Jones <da...@hotwaxmedia.com> wrote:
> From: David E Jones <da...@hotwaxmedia.com>
> Subject: Re: LocalizedMap.java - Do we really need it?
> To: dev@ofbiz.apache.org
> 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
Re: LocalizedMap.java - Do we really need it?
Posted by David E Jones <da...@hotwaxmedia.com>.
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
Re: LocalizedMap.java - Do we really need it?
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>