Okay, I think we're safe. I recently refactored all of that to make it
more reliable. If something breaks, the places to look are the
org.ofbiz.minilang.method.conditional.Compare class and
org.ofbiz.minilang.MiniLangUtil.convertType(...) method.
-Adrian
On 5/21/2012 3:42 PM, Adrian Crum wrote:
As far as Mini-language is concerned, I think it only affects the
comparison operators. But those comparisons should specifically check
for null, not compare something to GenericEntity.NULL_FIELD. Let me
look at them again.
-Adrian
On 5/21/2012 3:38 PM, Adam Heath wrote:
On 05/21/2012 09:36 AM, Adrian Crum wrote:
I meant putting GenericEntity.NULL_FIELD in the map with the "null"
key.
In other words, I am in favor of your changes. Sorry for the confusion.
You still didn't answer how removing it could break things. Unless
you meant that was a thinko. And if it was, you didn't correct it.
I'm about to commit my changes, except for the "null" stuff. If I
get your ok, I'd commit that too.
-Adrian
On 5/21/2012 2:30 PM, Adam Heath wrote:
On 05/21/2012 07:41 AM, Adrian Crum wrote:
That is an ugly workaround that I would like to see go away.
Removing it
could potentially break a lot of things.
Do you mean that putting "null" into the context is an ugly
work-around, and that it should not be done, as I suggest? And are you
also saying that removing it would cause breakage on pages that depend
on "null" resolving to NullField?
-Adrian
On 5/21/2012 6:48 AM, Adam Heath wrote:
Why do SimpleMethod.java and ModelScreen.java both do
context.put("null", GenericEntity.NULL_FIELD)? That changes *all*
null
values in freemarker into that static instance, even when the target
type of the variable is *not* going to be part of some
entity-like map.
If I remove both of those calls(actually, remove one, change the
other
to place it as "nullField"), then the broken ordermgr link given
earlier starts to finally work. And, I think that even the nullField
constant should not be removed, as NullField should only be used
internally by the entity engine.
