I doublechecked the spec and the current Resin behavior is the proper
behavior. I don't think this behavior has changed in the spec, so the
old behavior was a bug. You can't use the empty operator to test for
the existence of fields (or methods).
As to the rationale for the spec... it does make some amount of sense,
helping to reduce one very common type of bug (I'm getting properties
of a ThingA and the object turns out to be a ThingB). I'm sure all
the arguments for static typing vs duck typing apply here.
Note: There is nothing special about the empty operator; expressions
are resolved as normal and then the result is tested for null or empty
collection. If expression evaluation ever tries to access a field or
method that doesn't exist on an object, the EL resolver throws
PropertyNotFoundException or MethodNotFoundException.
Jeff
On Fri, May 7, 2010 at 2:47 PM, Aaron Freeman <aaron.free...@layerz.com> wrote:
> This isn't in the UI layer. This is in a controller. At any rate there is
> a simple work around, but this sure doesn't seem like it should be
> generating an error. If a property doesn't exist on an object it sure seems
> like the test for empty=true should work, and not throw a runtime error.
>
> At any rate there are easy workarounds in this case but workarounds make the
> code uglier.
>
> Aaron
>
>
> On 5/7/2010 3:57 PM, Jon Stevens wrote:
>
> I don't know if there is a way and it isn't something I'd depend on in the
> UI layer. Think of [class] like you'd think of an interface. You really
> should only put implementations of interfaces into the context. Otherwise,
> I'd consider putting a Map in there for the effect you want.
> jon
>
> On Fri, May 7, 2010 at 1:43 PM, Aaron Freeman <aaron.free...@layerz.com>
> wrote:
>>
>> Bummer, what's the proper way to test if a property exists then, since
>> ${!empty [class].[property]} isn't the correct way?
>>
>> Thanks,
>>
>> Aaron
>>
>>
>> On 5/7/2010 3:07 PM, Jon Stevens wrote:
>>
>> That is what JBoss does, so I'd say that Caucho fixed a bug.
>> jon
>>
>> On Fri, May 7, 2010 at 12:59 PM, Aaron Freeman <aaron.free...@layerz.com>
>> wrote:
>>>
>>> We are system testing Resin 4.0.6 with our old code base and found a
>>> curiosity. The following code used to work, regardless of what "type"
>>> "receipt" is:
>>>
>>> <c:if test="${!empty receipt.details}">
>>>
>>> Under Resin 3.0.x if receipt was a HashMap and had a "details" property
>>> then it would return "true". If it was a HashMap and did not have a
>>> details property, it would correctly return false. And (most
>>> importantly), if receipt was _any_ other class, including built in java
>>> classes, it would just return false. With Resin 4.0.6 it now throws an
>>> error:
>>>
>>> 'details' is an unknown bean property of 'java.math.BigDecimal'
>>>
>>> That's not the expected behavior is it?
>>>
>>> Thanks,
>>>
>>> Aaron
>>>
>>
>
>
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
>
_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
