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
