OFBiz › OFBiz - Dev

LocalizedMap.java - Do we really need it?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Adrian Crum

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

Adrian Crum

Re: LocalizedMap.java - Do we really need it?

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
>

David E Jones-3

Re: LocalizedMap.java - Do we really need it?

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

Adrian Crum-2

Re: LocalizedMap.java - Do we really need it?

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 <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: LocalizedMap.java - Do we really need it?
> To: [hidden email]
> 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

David E Jones-3

Re: LocalizedMap.java - Do we really need it?

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 <[hidden email]>
> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: LocalizedMap.java - Do we really need it?
>> To: [hidden email]
>> 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
>
>
>

Adrian Crum-2

Re: LocalizedMap.java - Do we really need it?

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 <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: LocalizedMap.java - Do we really need it?
> To: [hidden email]
> 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
> <[hidden email]>
> > wrote:
> >
> >> From: David E Jones
> <[hidden email]>
> >> Subject: Re: LocalizedMap.java - Do we really need
> it?
> >> To: [hidden email]
> >> 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
> >
> >
> >

Adrian Crum-2

Re: LocalizedMap.java - Do we really need it?

In reply to this post by David E Jones-3

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 <[hidden email]> wrote:

David E Jones-3

Re: LocalizedMap.java - Do we really need it?

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 <[hidden email]>
> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: LocalizedMap.java - Do we really need it?
>> To: [hidden email]
>> 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
>
>
>

Adrian Crum-2

Re: LocalizedMap.java - Do we really need it?

In reply to this post by Adrian Crum

--- On Fri, 12/12/08, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: LocalizedMap.java - Do we really need it?
> To: [hidden email]
> 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

David E Jones-3

Re: LocalizedMap.java - Do we really need it?

On Dec 13, 2008, at 8:46 AM, Adrian Crum wrote:

> --- On Fri, 12/12/08, David E Jones <[hidden email]>
> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: LocalizedMap.java - Do we really need it?
>> To: [hidden email]
>> 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

Adrian Crum-2

Re: LocalizedMap.java - Do we really need it?

--- On Sun, 12/14/08, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: LocalizedMap.java - Do we really need it?
> To: [hidden email]
> 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
> <[hidden email]> wrote:
> >
> >> From: David E Jones
> <[hidden email]>
> >> Subject: Re: LocalizedMap.java - Do we really need
> it?
> >> To: [hidden email]
> >> 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