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