11:02 p.m.
>>>> On Mon, 24 Aug 2009 17:29:11 -0400, Andy Schwartz
<andy.schwartz(a)oracle.com> said:
AS> Right. Behaviors are created and wired into the component tree during
AS> tag/handler execution. The event name is used during this process - ie.
AS> is specified when registering the Behavior with the hosting
AS> UIComponent. In theory we could allow the event name to be specified
AS> via an EL expression, but the spec would need to be clear that this EL
AS> expression would be evaluated immediately during tag/handler execution
AS> (as the component tree is built) rather than deferred/re-evaluated
AS> during later phases.
Which begs the question: do we need to re-introduce immediate evaluation
for EL expressions? In other words, do we bring back $?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
3:38 p.m.
New subject: [jsr-314-open] [AjaxBehaviorEventAttribute] why must it be a literal?
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
10:24 a.m.
New subject: [jsr-314-open] [AjaxBehaviorEventAttribute] why must it be a literal?
Am Donnerstag, den 27.08.2009, 09:38 -0400 schrieb Andy Schwartz:
Hi Ed -
Ed Burns wrote:
> Which begs the question:
see: http://begthequestion.info/
> do we need to re-introduce immediate evaluation
> for EL expressions? In other words, do we bring back $?
>
Andy wrote:
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.
the Facelets-Taghandler-API actually does support immediate evaluation
of tag-attributes. See javadoc of:
javax.faces.view.facelets.TagAttribute.getObject()
What Facelets doesn't support is recognising '$' as indicator for
immediate evaluation (and making use of it in ComponentHandler-class).
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.
I'm in favor to support '$' for immediate-evaluation (for any
attribute). It allows the page-author to indicate that an attributes
value is not intendet to change during the lifetime of that view. (Which
saves quite a number of redundant re-evaluations of EL-Expressions)
- Norbert
Andy
> Ed
>
>
9:04 p.m.
New subject: [jsr-314-open] [AjaxBehaviorEventAttribute] why must it be a literal?
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(a)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
9:05 p.m.
New subject: [jsr-314-open] [AjaxBehaviorEventAttribute] why must it be a literal?
And note that the $ wouldn't work anyway because there are some cases the
that developer simply cannot control. The VE may have to be resolved during
build time, for instance.
-Dan
On Fri, Aug 28, 2009 at 3:04 PM, Dan Allen <dan.j.allen(a)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(a)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
--
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
5360
days inactive
5363
days old
jsr-314-open-mirror@lists.jboss.org
4 comments
4 participants
participants (4)
-
Andy Schwartz -
Dan Allen -
Ed Burns -
Norbert Truchsess