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 <[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, 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 > <[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, 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 > > > > > >
