• Post Reply Bookmark Topic Watch Topic
  • New Topic

Using c:set with target attribute

 
Ian Perkins
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Please could someone explain why...

<c:set target="myBean" property="x" value="y"/>

throws an exception (invalid property), whereas...

<c:set target="${myBean}" property="x" value="y"/>

works perfectly!

Why should the target attribute have to be expressed in EL?

i'm sure there is a reasonable explanation but I just can't see it...

Thanks

Ian
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
108
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because "myBean" is a string while "${myBean}" is a scoped variable reference. You are setting the property onto a bean that is a scoped variable, so you need the latter notation to tell the <c:set> tag so.
 
Ian Perkins
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bear,

Thanks for the reply - I understand this but do you know why this is inconsistent with the standard actions which take a string as the value supplied to the name attribute? e.g. <jsp:setProperty name="x".../>

According to the JSTL documentation on the Sun website, the type of the target attribute is String so what is the run-time type of the object passed to the setTarget method of the <c> tag?

Actually, I guess I _should_ check the source code myself!

Thanks again

Ian
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
108
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The JSTL and the standard actions do approach this differently. And while it appears to be inconsistent, it gives the JSTL much more flexibility.

With the simple string of the standard actions, deep referencing is not possible, but with <c:set> something like the following:



where the target bean is a deep reference is possible.
 
Ian Perkins
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry, I should have downloaded the source code before posting :-(

I am new to all this and just downloaded the nearest implementation I could find without really looking at the differences...

Turns out I am using the org.apache.taglibs.standard.tag.rt.core implementation of SetTag - the arg to setTarget is an Object so it must have been evaluated before the setter is invoked.

The org.apache.taglibs.standard.tag.el.core implementation accepts a String and then searches the scope objects to locate the bean/Map whose id is passed in the setTarget method.

What I have to do now is to try to understand the differences between all of these implementations!

Which do you use as a standard? Is one of them redundant now in JSP 2.0?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
108
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, under JSP 2 you should be using JSTL 1.1 which does not have the rt/non-rt schizophrenia (since in JSP 2 it becomes the container's responsibility to evaluate EL expression before they get passed to the tags).

My recommendation for everyone is -- unless there is a strong business reason otherwise -- to upgrade to a JSP 2.0 container (e.g. Tomcat 5, Resin 3) and JSTL 1.1 as soon as possible.
[ September 02, 2004: Message edited by: Bear Bibeault ]
 
Ian Perkins
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks!

I am still a bit confused about why the JSTL 1.1 TLD for the core tags i.e. c.tld, points to the tag class files in package ...tag.rt.core (where the implementation is expecting an Object to be passed) whereas there are class files in package ...tag.el.core which expect String args.

I am using a copy of Pro JSP (JSP 2.0 and Servlet 2.4) which states that the 'rt' implementations are for backwards compatibility with scripting expressions and that the 'el' implementations are there to support the EL... this doesn't seem quite right (!)

Ah well, thanks again for the insights and advice...
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!