Re: Hashes (in general)

Wednesday, June 10, 2009, 10:09:48 AM, Attila Szegedi wrote:

> On 2009.06.10., at 9:52, Daniel Dekany wrote:
>
>> Tuesday, June 9, 2009, 4:57:11 PM, Brian Pontarelli wrote:
>>>
>>> Yeah. It doesn't unwrap the map directly. It creates a special Map
>>> that is an adapter with a custom entry set. It definitely can make  
>>> things messy.
>>
>> What did you use for unwrapping (and what was the ObjectWrapper)? If
>> you use BeansWrapper and call a plain Java method, it should give you
>> back the original Map.
>
> DefaultObjectWrapper will do that... DefaultObjectWrapper is a  
> BeansWrapper that hijacks BeansWrapper wrapping logic for strings,  
> numbers, dates, lists, arrays, and maps, and diverts it to creation of
> SimpleXxx models. SimpleHash creates a private map copy, and can't  
> expose it back (it doesn't implement AdapterTemplateModel), so the  
> BeansWrapper.unwrap() has to resort to creating a new  
> f.ext.beans.HashAdapter (which is a TemplateHashModel->java.util.Map  
> adapter).

You said "DefaultObjectWrapper will do that". Now then does it do that
or not?

> You can tell I *really* dislike DefaultObjectWrapper and its penchant
> for creating SimpleXxx models; it quite carelessly breaks some  
> intuitively expected behaviour, like expectation of being able to pass
> a Map returned from one Java method to another Java method.
>
> As I already said, just use BeansWrapper.

Me too... So that's already 2 out of the 3 "key personal".

> It preserves identity of
> objects bidirectionally (passing back to Java from Java), doesn't  
> create copies of collections, and in general behaves intuitively. If  
> you dislike having map methods visible, use BeansWrapper with  
> setSimpleMapWrapper(true).

This is freemarker-devel topic at this point, but... I think there are
some core problems with the whole wrapping thing. Like, at least
apparently (and them AFAIK also actually), it meant to be global in
effect. But when you write your FTL code that accesses some Java
objects, you certainly have an assumption regarding how the Java
object is exposed. So, as the author of some page template maybe you
think you would prefer setSimpleMapWrapper(true), but with that you
possibly break some FTL libraries... things like that. So after all,
maybe the be best is to leave simpleMapWrapper at false, and then just
use the Java API methods to get the keys and like. (Or what else
should user do?) But that defeats the point of wrapping, which is that
the concrete Java-side types are hidden. So it's like there is a nice
theory about transforming the data-model and hiding types that wasn't
worked out very well in real-word environment... Maybe just because it
wasn't applied properly, like the API suggests practices that lead to
a messy situations. I guess there should be an unchangeable built-in
wrapper, kind of part of the template language, and then the special
wrappings should be the exceptions where you should be very explicit
about your intent. Like, you could say that all com.example.User
objects should wrapped with MyUserWrapper. But you couldn't say the
same for java.util.Map for example.

> Attila.
> --
> http://twitter.com/szegedi
>
>>
>>> -bp
>>>
>>
>> -- 
>> Best regards,
>> Daniel Dekany

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