Re: Hashes again

Tuesday, June 9, 2009, 7:42:48 PM, Brian Pontarelli wrote:

> I've been playing around with the BeansWrapper, but it doesn't really
> behave as expected (at least as I thought it would).
>
> The first issue I ran into was that I couldn't figure out the syntax  
> to get something out of a Map<Integer, String>. I tried these  
> variations with no luck:
>
>         - bean.map(1)
>         - bean.map.get(1)

Yeah... It doesn't work because FTL has only a single numerical type,
while Java has more. Since in Java you can't get an Integer keyed
value with a BigDecimal key (which FTL usually uses to store numbers
that are produced in FTL), you have to give FTL a hint regarding the
exact type of the key:

         - bean.map(1?int)
         - bean.map.get(1?int)

Note that you don't need to do this if the number comes from a Java
API that already uses int or Integer. For example this should work:
bean.map(myObject.myIntReturningMethod()).

>         - bean.map[1]

That won't work, since [] is an operator for the hash type (not for
Map-s), which always uses string keys.

> The second thing I noticed is that Map's aren't really Map's any  
> longer. They are now Object's. This means that their keys sequence  
> contains their methods, which is really not what I want.

Yip, that's because in FTL, unlike in Java, there is not separate
namespace for methods, fields, and Map items. That's why you can write
myObject.myField, myObject.myMethod (and then call it),
myObject.myMapItemWithStringKey, but that also a source of lot of
confusion. But, it's up to the ObjectWrapper if what names will be in
that namespace. With myObjectWrapper.setSimpleMapWrapper(true), only
the Map items are exposed in Map-s. Another possibility is to
myObjectWrapper.setSimpleMapWrapper(false) (the default in 2.3.x, but
not in 2.4 at the moment), but then use myMap.keySet() to get the
keys.

> I guess what I'm wondering is if there is a way to have these things:
>
>         - Have FM work with Collections only as collections, without any
> monkeying around with Map keys or creating new collections that adapt
> the original collections

You can do hat simply by exposing and calling the original Java API
methods. Use BeansWrapper with setSimpleMapWrapper(false), and that
should be so then.

>         - Have FM treat other non-primitives as JavaBeans as well as  
> reflectable classes

It does that with the BeansWrapper (with setSimpleMapWrapper(false)).

> It seems to me that FM should be capable of handling all of these  
> cases with Maps that would solve the first requirement:
>
>         1. bean.map[0]
>         2. bean.map.key
>         3. bean.map['foo']
>         4. bean.map[otherObject]

(ATM these work for string keys only...)

> #1 would assume Map<Integer, Object>, #2 would assume Map<String,  
> Object>, #3 would assume Map<String, Object>, and #4 would assume
> Map<Object, Object>.

Well, it doesn't mater what it assumes, given the Java API has only
Map.get(Object)... the generics stuff is there mostly only on the
compiler level. Anyway, you are basically saying is that
TemplateHashModel should be deprecated in favor of a new
TemplateMapModel type that accepts keys of arbitrary type, and maybe
that integer FTL literals should be internally represented as Integers
rather than BigDecimals (then #1 would work).

> This would cover all cases and not interfere with
> other collections because these cases would only apply if 'bean.map'  
> implemented Map. In fact, if your wrapped object instance has generics
> that can be inspected from the Java code, this becomes even better and
> #1 could figure out the Number sub-class to use. All the other cases  
> could use toString on the key if the Map is in fact Map<String, Object>.
>
> -bp

-- 
Best regards,
 Daniel Dekany


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