On 5/7/2010 5:39 PM, Jeff Schnitzer wrote:
> 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).
You might want to take a look at a project I created several years ago
that works pretty much like this. I still find it occasionally
useful, although most of my frontends are GWT and javascript these
days:
http://tagonist.tigris.org/
It lets you use JSP files as controllers but keeps your Java
Yes, that's exactly right. In several instances we have many
controllers that are written in JSP (pure JSTL code), that
our models (also in this case JSPs) and also our views.
Works great!
The upside to it is: a) easier to code -- people with limited Java
expertise can modify the controller
On May 7, 2010, at 15:39:37, Jeff Schnitzer wrote:
> 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 o
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
This comment isn't helpful I know but I am very curious about this.
The code you quoted is a tag library call using the EL. How is that
not part of the UI? Are you writing controllers in JSP somehow?
Rachel
On Fri, May 7, 2010 at 2:47 PM, Aaron Freeman wrote:
> This isn't in the UI layer. Thi
I've always written code that assumes empty returns false if the property
doesn't exist. I haven't checked the spec, but throwing an exception seems like
the wrong thing to do.
--
Rick
On May 7, 2010, at 14:47:21, Aaron Freeman wrote:
> This isn't in the UI layer. This is in a controller. A
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.
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, Ma
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
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 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:
>
>
>
> Under Re
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:
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
12 matches
Mail list logo