On 05/18/2012 12:52 AM, Jacopo Cappellato wrote:
On May 18, 2012, at 7:02 AM, Adam Heath wrote:
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.
I agree on the general rule; unfortunately there are exceptions where enforcing
this rule is too problematic; however I agree that the practice of calling the
delegator API from FM is used much more than it should.
Apart from moving data preparation code to data preparation scripts where
possible, we could also define a FM transform to implement these calls and this
will protect the access to the delegator because in the transform we would
perform all the necessary null checks etc...
The risk is to end up with a big sets of transforms that re-implement the
delegator API, but we could start by implementing the calls that are currently
clearly broken (findByAnd) and then create new ones (or refactor existing code)
*before* you will refactor other delegator methods.
In this way we will have a temp fix (waiting for the official fix from FM) and
also a better implementation of templates (that execute calls to delegator only
thru a transform)
This problem with null parameter values in freemarker only occurs when
there are multiple methods with the same name. If there is only a
single method with a name, then no overridden resolution logic happens.
That's how the freemarker code functions.
So, if my new findByAnd variant gets a new name, then all can be well.
This is how find() and findList() got implemented, and why we never
noticed this freemarker problem before.
So, any suggestions for a new name?
