On May 18, 2012, at 7:56 AM, Adam Heath wrote: > 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?
Would it make sense to wrap the delegator before adding it to the context of Freemarker? In this way we could "fix" the call for freemarker only and keep the official API as clean as possible. Jacopo
