About the Freemarker's wrapper used by OFbiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Recently I have been in contact with a couple of Freemarker's committers that helped me to fix a deadlock condition happening because of two bugs (one in OFBiz and one in Freemarker); in the email thread (available in the Freemarker user list archives) we discussed also about the way we use BeansWrapper in OFBiz; here is the relevant part of the conversation:

=====================================================
Q: Do you think we should use a different object wrapper?

A: I'm not sure. There are two problems with the current one:

- If you look at what map keys FreeMarker sees (`<#list k as
  someMap?keys>${k} </#list>`), it mixes the actual Map keys with the
  methods of the Map class. This I already find annoying enough to
  stay away. But it's also dangerous, because if you are unlucky and
  have key like "get", then someMap.get and someMap[myDynamicKey]
  where myDynamicKey happens to be "get" will return the get method
  instead of the map item. You can think further what if you have
  a custom Map class and you add methods to it. Using
  someMap.get("theKey") is robust however, but too verbose.

- It doesn't wrap W3C DOM nodes automatically in a way so that the
  user can use FreeMarker's XML processing facility. It also doesn't
  wrap Jython or Rhino JavaScript objects nicely.

What I like to use is:

   BeansWrapper wrapper = new BeansWrapper();
   wrapper.setSimpleMapWrapper(true);

This will not expose the methods of Map-s, only the keys of it. If you
want to get a map item that has a non-string key, you don't have
someMap.get(key) anymore, but you can use someMap(key) instead. If
it's a custom Map class with custom methods that you want to call from
the template, then you are out of luck, however. And in your case
these changes wouldn't be backward-compatible.

As of supporting W3C DOM nodes, Jython and such, it's very easy to
create a custom ObjectWrapper that does that. Just look at
DefaultObjectWrapper.

As of DefaultObjectWrapper, it's burdened with backward-compatibly,
and so wraps collections on an technically awkward way, plus it
doesn't provide any hacks for the non-String key problem. I don't see
a point of using that.

Anyway, the situation with Map-s and the "advertised" object wrappers
is something that had to be hammered out for ages. Sadly nobody has
found the time/incentive for it so far...
=====================================================

Ok, this is what I got from them; I am testing locally a replace DefaultObjectWrapper with the wrapper suggested by Daniel and I will let you know the outcome; in the meantime I wanted to share with you these details.

Jacopo