On 05/17/2012 11:50 PM, Adam Heath wrote:
On 05/17/2012 12:23 PM, Jacopo Cappellato wrote:
file are attached; that bug tracker is really awful.
This is all becoming very troubling.
== example methods
String a(String name, List list) {}
String a(String name, Map map) {}
String a(Object[] args) {}
String b(String name, List list) {}
String b(String name, Map map) {}
String b(Object... args) {}
== example templates
${object.a(string, null)}
${object.b(string, null)}
==
In 2.3.18, freemarker can't find any methods at all. In 2.3.19, it can
find the b vararg method. In either situation, that is wrong.
The correct situation for both is to say there are 2 matching methods,
the List and Map variants. Without my patch, when a null is used, any
non-primitive method will never be considered as a possible candidate.
I'm still discussing with freemarker upstream, but I get the feeling
that they won't provide a fix for the 2.3 branch, and a true, correct
fix for 2.4 will be long in coming.
This means we need to come up with a workaround for ofbiz. I'm up for
suggestions. We really can't undo the change, that just doesn't seem
right to me.
In detail, using a null in a method call inside freemarker will be
*extremely* problematic. Even if I rename my new findByAnd to smoething
else, passing a null to it will keep freemarker from finding it.
Imho, we should *not* be calling into the delegator inside freemarker
templates. Templates should not be tied to the backend *at all*. They
should only deal with 100% completely generic collection objects.
Because they are currently tied to the delegator, this makes it
*impossible* to have a separate web-frontend, that isn't tied to ofbiz
at all.
