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 <mailto: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 <mailto: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
