On Fri, Aug 28, 2009 at 3:04 PM, Dan Allen <dan.j.allen@gmail.com> wrote:

I side with Andy that we don't want to introduce the complexity of two symbols, especially since the meaning has been diluted already. What is better is to improve the documentation to explicitly state when a value expression is resolved. We need this anyway since there are other build time and render time cases. Perhaps we need an extra symbol or flag in the documentation so it is easy to tell which one it is.

In general, I think the next version of the spec is going to have to be a lot more detailed about this idea of build time behavior and render time behavior. There are loads of blog entries that attempt to raise awareness that there is a difference. Most notably the c:forEach vs ui:repeat tag.

-Dan

On Thu, Aug 27, 2009 at 9:38 AM, Andy Schwartz <andy.schwartz@oracle.com> wrote:

Hi Ed -

Ed Burns wrote:

Which begs the question: do we need to re-introduce immediate evaluation
for EL expressions? In other words, do we bring back $?

I don't believe that this is necessary. Facelets of course does not support the concept of "immediate" expressions - ie. the Facelets engine itself does not evaluate EL expressions. I don't believe that we want to change this. Instead, we should simply follow the pattern that is already used by other tags that evaluate EL expressions during tag/handler execution, such as the JSTL tags. That is, we should allow the Facelets engine to create a (deferred) ValueExpression that happens to be evaluated by the Behavior handler when the handler is applied, similar to the way the c:forEach "items" attribute is handled today.

Andy

Ed

--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan