Deferred EL in dynamic attributes
According to the Sun Java EE 5 tutorial, using deferred EL ( #{} syntax) is forbidden for usage in a tag's dynamic attributes.
What's the exact use of making this illegal? (what problem does this rule solve?)
Anyway, I'm asking since I have developed lots of JSF 1.1 components with dynamic attributes that accept EL expressions. Technically it's not a problem. In the tag handler, I just itterate over all collected attributes, check if they're EL using the JSF API and if so create a value binding for them.
However, in JSP 2.1/JSF 1.2 the container prevents the "#{...}" string from reaching my tag handler code. This is very nasty. I can of course disable container evaluation for the entire page, but this is quite an ugly solution.
Is there any neat workaround for this problem?
[820 byte] By [
flowerpa] at [2007-11-26 13:37:31]
# 1
Actually, it's not illegal. One item to note though, is that all of the ValueExpressions set by the container in this case, will only returnObject, so no coercion will take place by default.
# 2
> Actually, it's not illegal. I think it is, according to http://java.sun.com/javaee/5/docs/tutorial/doc/JSPIntro7.html , from which I quote:>Note that it is illegal to use #{} syntax for a dynamic attribute
# 3
I believe the tutorial is incorrect. In fact, I recall doing this while the JSP 2.1 spec was in progress and found that the spec didn't cover it. I was able to get the spec leads to cover this within the spec before the release. When in doubt, check the 2.1 spec.I'm guessing that the tutorial has a doc error.
# 4
> When in doubt, check
> the 2.1 spec.I'm guessing that the tutorial has a
> doc error.
You're right, I checked the (may 2006) JSP 2.1 spec, and on page 2-72, section 3 it says:
>Dynamic attributes must be considered to accept request-time expression values
>as well as deferred expressions.
So, the tutorial is definitely wrong.
Maybe someone should notify Sun about this? It seems most people would resort to reading tutorials first instead of wading through the spec. Especially if a Sun tutorial states something, many people will probably consider it 'official'. Perhaps even the Tomcat folks have read said tutorial instead of the spec. Using an EL value in a dynamic attribute in Tomcat 6 causes a translation error.
Btw, I'm not 100% sure how to interpret this note from the spec:
>Note that passing a String literal as a dynamic attribute will never be considered
>as a deferred expression.
What other way is there to pass a deferred expression than through a String litteral?
# 5
>Btw, I'm not 100% sure how to interpret this note from the spec:
>>Note that passing a String literal as a dynamic attribute will never be >>considered
>>as a deferred expression.
>What other way is there to pass a deferred expression than through a String >litteral?
Well, in the case where an attribute is defined as accepting a deferred expression (not dynamic), if a literal value is passed (i.e. no #{...}), then the container will create a ValueExpression that will return the literal value.
In the case of dynamic attributes, if a literal is provided (i.e. no #{...}) then
it won't be converted to a ValueExpression, it will just be a String.
# 6
With regards to the tutorial, I'll make sure they're aware of the issue.
# 7
From one of our esteemed tutorial writers...
Hi,
The sentence you quote from the tutorial was referring to the dynamic attributes described in section 2.3.2 of the JSP 2.1 specification which are attributes that accept runtime expressions, not the dynamic attributes that refer to attributes that are not necessarily known at runtime.
It's unfortunate that the spec uses these terms to describe two different concepts. I thought that the table following the statement in the tutorial would make it clear which concept I was referring to (note the example rtexprvalue tags), but I can see why you thought I meant the other kind of dynamic attribute.
Would the following change to the tutorial help to clarify this?:
Note that it is illegal to use |#{}| syntax for a dynamic attribute, meaning an attribute that accepts dynamically calculated values at runtime, or |${}| syntax for a deferred attribute.
Thanks.
Jennifer
