Re: Hashes (in general)

DefaultObjectWrapper (what FM uses by default) is actually a subclass  
of BeansWrapper. I don't think you can go wrong with switching to  
BeansWrapper.

Attila.

On 2009.06.09., at 16:52, Brian Pontarelli wrote:

> The problem is actually in Java code. The issue is going from Java to
> FTL to Java like this:
>
> 	1. Java code creates Map and puts it in the FTL context
> 	2. FTL passes variable to a custom directive via a parameter
> 	3. Java code unwraps the passed in value
>
> I guess if I used the BeansWrapper it would correctly wrap and unwrap
> because FM wouldn't be mutating the Map during this process. The
> implications of using BeansWrapper in JCatapult could be large though
> and I not sure I could change it. I'll look into it though.
>
> -bp
>
> On Jun 9, 2009, at 12:58 AM, Attila Szegedi wrote:
>
>> You can make sure to use BeansWrapper instead of either
>> SimpleObjectWrapper or DefaultObjectWrapper. Then, use the syntax
>> map(key) instead of map[key] or map.keyStr, where you can pass
>> arbitrary non-string keys. If "key" evaluates to a wrapped Java
>> object, the lookup will be performed using the unwrapped Java object,
>> as expected. The ability to use the function syntax map(key) on
>> wrapped Java Maps is a specialty of the  BeansWrapper.
>>
>> Attila.
>>
>> On 2009.06.08., at 22:57, Brian Pontarelli wrote:
>>
>>> I've been using FM for a while now and I just ran into a interesting
>>> snag. I knew that Hashes define in the FTL files had to have a  
>>> String
>>> for the key. This seems like it is to support the 'foo.bar' syntax
>>> (which I'm a huge advocate against). However, I'm using JCatapult,
>>> which takes properties and fields of an action class and puts them
>>> into the root FM context. I have this:
>>>
>>> public class Foo {
>>> public Map<Integer, String> guests;
>>> public Map<Integer, String> miles;
>>>
>>> public void setupForm() {
>>>   guests.put(1, "1");
>>>   ...
>>> }
>>> }
>>>
>>> This Map is then being passed to a custom Directive as an attribute
>>> like this:
>>>
>>> [@jc.select items=guests name="q.guests"/]
>>>
>>> There are a few issues I'm running into.
>>>
>>> 1. FM seems to wrap this Map and rather than converting the keys to
>>> Strings during wrapping, it keeps the original map around and seems
>>> to
>>> incorrectly duplicate the keys with String versions whose values are
>>> all null.
>>>
>>> 2. I get random ConcurrentModificationExceptions out of FM if I use
>>> an
>>> iterator like this:
>>>
>>>  for (Map.Entry e : map) {
>>>    ...
>>>  }
>>>
>>> So, my questions are:
>>>
>>> - Will 2.4 or some other version will support Maps with any type of
>>> key so that frameworks can use Object comparisons (via the equals
>>> method)?
>>>
>>> - Is there a way currently to get FM to stop wrapping the Map with  
>>> an
>>> incorrect version that has String keys and null values?
>>>
>>> Thanks,
>>> -bp

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects