3:06 a.m.
Thanks Lincoln. I haven't had time to debug this, but I have a theory
about what might be happening. In your sample:
<a:editText value="#{cc.attrs.task.text}"
rendered="#{!cc.attrs.disabled}">
*<f:actionListener for="submit"
action="#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}"
/> *
</a:editText>
We expect "cc" to resolve to the containing composite component (ie. to
the <socialpm:taskBlock> component). I wouldn't be surprised if what is
actually happening is that "cc" is being resolved to the <a:editText>
composite component instead. One reason why I suspect this might be
happening is that I know that Ryan has investigated/resolved similar
problems not too long ago. Another reason why I am suspicious about
this is because we have faced similar issues in our own (ADF Faces)
declarative component solution. This stuff can get tricky. :-)
Hey Ryan -
Does this problem look familiar? Any thoughts on this?
Andy
Lincoln Baxter, III wrote:
> Hey Andy, here you go:
>
> In the mean time I'm going to sign up for the dev lists.
>
> ----------------------------------------------------------------------
> Using:
> <f:actionListener for="submit"
> action="*#{taskController.saveTaskAjax(cc.attrs.story,
> cc.attrs.task)}*" />
>
> *#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}* =
> null values passed to method
> *#{taskController.saveTaskAjax(currentStoryBean.story, task)}* =
> correct values resolved, assuming currentStoryBean.story and task
> are both in the EL/page scope somewhere.
>
>
> ----------------------------------------------------------------------
> *CC Impl:*
>
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:a="http://java.sun.com/jsf/composite/ajax"
> xmlns:cc="http://java.sun.com/jsf/composite">
> <cc:interface>
> <cc:attribute name="story" required="true"
type="Object" />
> <cc:attribute name="task" required="true"
type="Object" />
> <cc:attribute name="disabled" required="false"
type="Boolean"
> default="false" />
> <cc:insertChildren />
> </cc:interface>
>
> <cc:implementation>
> <h:outputStylesheet name="socialpm/socialpm.css" />
> <h:panelGroup id="taskBlock" layout="block"
class="box-bordered p5
> #{cc.attrs.styleClass} taskBlock_#{cc.attrs.task.status}"
> style="#{cc.attrs.style}">
>
> <div class="m5l" style="margin-right: 25px;" >
> <h:outputText value="#{cc.attrs.task.text}"
> rendered="#{cc.attrs.disabled}"/>
<a:editText value="#{cc.attrs.task.text}"
rendered="#{!cc.attrs.disabled}">
*<f:actionListener for="submit"
action="#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}"
/> *
</a:editText>
> </div>
> </cc:implementation>
> </html>
>
>
> ----------------------------------------------------------------------
> *consuming page code:* <-- this is where task is defined in the
> UI:Repeat, so it is in scope
>
> <!DOCTYPE html
> PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:c="http://java.sun.com/jsp/jstl/core"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:socialpm="http://java.sun.com/jsf/composite/socialpm"
> xmlns:pretty="http://ocpsoft.com/prettyfaces"
> xmlns:ui="http://java.sun.com/jsf/facelets" xml:lang="en"
lang="en">
>
> <ui:composition>
> <h:form id="tasksForm">
> <c:if test="#{empty currentStoryBean.story.tasks}">
> <div class="m5">This story has no tasks. That could be a problem
> later...</div>
> </c:if>
>
> <ui:repeat value="#{currentStoryBean.story.tasks}"
var="task">
> <socialpm:taskBlock task="#{task}"
story="#{currentStoryBean.story}"
> members="#{currentProjectBean.project.activeMembers}"
> disabled="#{!authorizationBean.isMember or !currentStoryBean.story.open}"
> deletable="true" styleClass="m5t" refreshOnSave="false"
/>
> </ui:repeat>
> </h:form>
> </ui:composition>
> </html>
>
>
>
>
> On Sat, 2009-09-05 at 15:23 -0400, Andy Schwartz wrote:
>> Hey Lincoln -
>>
>> Lincoln Baxter, III wrote:
>> > First, please let me know if there is a better place to ask JSF Dev
>> > related questions.
>> >
>>
>> I suppose the Mojarra dev list might be the right place for
>> implementation questions:
>>
>> https://javaserverfaces.dev.java.net/mailinglists.html
>>
>> Though personally I am fine with you asking here. :-)
>>
>> Could you send along your composite component implementation (and
>> perhaps a snippet from the consuming page)? Just want to make sure I
>> understand the use case.
>>
>> Andy
>>
>>
>>
> --
> *Lincoln Baxter, III*
> Co-Founder of OcpSoft <http://ocpsoft.com>
> Author of PrettyFaces <http://ocpsoft.com/prettyfaces> URL Rewriting
> for JSF
>
>
6:59 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On 9/7/09 6:06 PM, Andy Schwartz wrote:
Thanks Lincoln. I haven't had time to debug this, but I have a
theory
about what might be happening. In your sample:
> <a:editText value="#{cc.attrs.task.text}"
> rendered="#{!cc.attrs.disabled}">
> *<f:actionListener for="submit"
> action="#{taskController.saveTaskAjax(cc.attrs.story,
> cc.attrs.task)}" /> *
> </a:editText>
We expect "cc" to resolve to the containing composite component (ie.
to the <socialpm:taskBlock> component). I wouldn't be surprised if
what is actually happening is that "cc" is being resolved to the
<a:editText> composite component instead.
Yep, that's what is happening.
One reason why I suspect this might be happening is that I know that
Ryan has investigated/resolved similar problems not too long ago.
The problem we
resolved was the passing of #{cc.attrs} attributes
between nested composite components.
For this case, the spec recommends using cc.parent.attrs.story and
cc.parent.attrs.task, where parent resolves
to the nearest composite component parent of the current composite
component.
Another reason why I am suspicious about this is because we have
faced
similar issues in our own (ADF Faces) declarative component solution.
This stuff can get tricky. :-)
Hey Ryan -
Does this problem look familiar? Any thoughts on this?
Andy
Lincoln Baxter, III wrote:
> Hey Andy, here you go:
>
> In the mean time I'm going to sign up for the dev lists.
>
> ----------------------------------------------------------------------
> Using:
> <f:actionListener for="submit"
> action="*#{taskController.saveTaskAjax(cc.attrs.story,
> cc.attrs.task)}*" />
>
> *#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}* =
> null values passed to method
> *#{taskController.saveTaskAjax(currentStoryBean.story, task)}* =
> correct values resolved, assuming currentStoryBean.story and task
> are both in the EL/page scope somewhere.
>
>
> ----------------------------------------------------------------------
> *CC Impl:*
>
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:a="http://java.sun.com/jsf/composite/ajax"
> xmlns:cc="http://java.sun.com/jsf/composite">
> <cc:interface>
> <cc:attribute name="story" required="true"
type="Object" />
> <cc:attribute name="task" required="true"
type="Object" />
> <cc:attribute name="disabled" required="false"
type="Boolean"
> default="false" />
> <cc:insertChildren />
> </cc:interface>
>
> <cc:implementation>
> <h:outputStylesheet name="socialpm/socialpm.css" />
> <h:panelGroup id="taskBlock" layout="block"
class="box-bordered p5
> #{cc.attrs.styleClass} taskBlock_#{cc.attrs.task.status}"
> style="#{cc.attrs.style}">
>
> <div class="m5l" style="margin-right: 25px;" >
> <h:outputText value="#{cc.attrs.task.text}"
> rendered="#{cc.attrs.disabled}"/>
> <a:editText value="#{cc.attrs.task.text}"
> rendered="#{!cc.attrs.disabled}">
> *<f:actionListener for="submit"
> action="#{taskController.saveTaskAjax(cc.attrs.story,
> cc.attrs.task)}" /> *
> </a:editText>
> </div>
> </cc:implementation>
> </html>
>
>
> ----------------------------------------------------------------------
> *consuming page code:* <-- this is where task is defined in the
> UI:Repeat, so it is in scope
>
> <!DOCTYPE html
> PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:c="http://java.sun.com/jsp/jstl/core"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:socialpm="http://java.sun.com/jsf/composite/socialpm"
> xmlns:pretty="http://ocpsoft.com/prettyfaces"
> xmlns:ui="http://java.sun.com/jsf/facelets" xml:lang="en"
lang="en">
>
> <ui:composition>
> <h:form id="tasksForm">
> <c:if test="#{empty currentStoryBean.story.tasks}">
> <div class="m5">This story has no tasks. That could be a problem
> later...</div>
> </c:if>
>
> <ui:repeat value="#{currentStoryBean.story.tasks}"
var="task">
> <socialpm:taskBlock task="#{task}"
story="#{currentStoryBean.story}"
> members="#{currentProjectBean.project.activeMembers}"
> disabled="#{!authorizationBean.isMember or
> !currentStoryBean.story.open}"
> deletable="true" styleClass="m5t" refreshOnSave="false"
/>
> </ui:repeat>
> </h:form>
> </ui:composition>
> </html>
>
>
>
>
> On Sat, 2009-09-05 at 15:23 -0400, Andy Schwartz wrote:
>> Hey Lincoln -
>>
>> Lincoln Baxter, III wrote:
>> > First, please let me know if there is a better place to ask JSF
>> Dev > related questions.
>> >
>>
>> I suppose the Mojarra dev list might be the right place for
>> implementation questions:
>>
>> https://javaserverfaces.dev.java.net/mailinglists.html
>>
>> Though personally I am fine with you asking here. :-)
>>
>> Could you send along your composite component implementation (and
>> perhaps a snippet from the consuming page)? Just want to make sure
>> I understand the use case.
>>
>> Andy
>>
>>
> --
> *Lincoln Baxter, III*
> Co-Founder of OcpSoft <http://ocpsoft.com>
> Author of PrettyFaces <http://ocpsoft.com/prettyfaces> URL Rewriting
> for JSF
>
>
7:18 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Ok. Ill try that. I just wanted to make sure that I didn't miss something, before I
check in this code to mojarra.
More when I get home, thanks!
Lincoln
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Ryan Lubke <Ryan.Lubke(a)Sun.COM>
Date: Tue, 08 Sep 2009 09:59:11
To: <jsr-314-open(a)jcp.org>
Subject: Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On 9/7/09 6:06 PM, Andy Schwartz wrote:
Thanks Lincoln. I haven't had time to debug this, but I have a
theory
about what might be happening. In your sample:
> <a:editText value="#{cc.attrs.task.text}"
> rendered="#{!cc.attrs.disabled}">
> *<f:actionListener for="submit"
> action="#{taskController.saveTaskAjax(cc.attrs.story,
> cc.attrs.task)}" /> *
> </a:editText>
We expect "cc" to resolve to the containing composite component (ie.
to the <socialpm:taskBlock> component). I wouldn't be surprised if
what is actually happening is that "cc" is being resolved to the
<a:editText> composite component instead.
Yep, that's what is happening.
One reason why I suspect this might be happening is that I know that
Ryan has investigated/resolved similar problems not too long ago.
The problem we resolved was the passing of #{cc.attrs} attributes
between nested composite components.
For this case, the spec recommends using cc.parent.attrs.story and
cc.parent.attrs.task, where parent resolves
to the nearest composite component parent of the current composite
component.
Another reason why I am suspicious about this is because we have
faced
similar issues in our own (ADF Faces) declarative component solution.
This stuff can get tricky. :-)
Hey Ryan -
Does this problem look familiar? Any thoughts on this?
Andy
Lincoln Baxter, III wrote:
> Hey Andy, here you go:
>
> In the mean time I'm going to sign up for the dev lists.
>
> ----------------------------------------------------------------------
> Using:
> <f:actionListener for="submit"
> action="*#{taskController.saveTaskAjax(cc.attrs.story,
> cc.attrs.task)}*" />
>
> *#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}* =
> null values passed to method
> *#{taskController.saveTaskAjax(currentStoryBean.story, task)}* =
> correct values resolved, assuming currentStoryBean.story and task
> are both in the EL/page scope somewhere.
>
>
> ----------------------------------------------------------------------
> *CC Impl:*
>
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:a="http://java.sun.com/jsf/composite/ajax"
> xmlns:cc="http://java.sun.com/jsf/composite">
> <cc:interface>
> <cc:attribute name="story" required="true"
type="Object" />
> <cc:attribute name="task" required="true"
type="Object" />
> <cc:attribute name="disabled" required="false"
type="Boolean"
> default="false" />
> <cc:insertChildren />
> </cc:interface>
>
> <cc:implementation>
> <h:outputStylesheet name="socialpm/socialpm.css" />
> <h:panelGroup id="taskBlock" layout="block"
class="box-bordered p5
> #{cc.attrs.styleClass} taskBlock_#{cc.attrs.task.status}"
> style="#{cc.attrs.style}">
>
> <div class="m5l" style="margin-right: 25px;" >
> <h:outputText value="#{cc.attrs.task.text}"
> rendered="#{cc.attrs.disabled}"/>
> <a:editText value="#{cc.attrs.task.text}"
> rendered="#{!cc.attrs.disabled}">
> *<f:actionListener for="submit"
> action="#{taskController.saveTaskAjax(cc.attrs.story,
> cc.attrs.task)}" /> *
> </a:editText>
> </div>
> </cc:implementation>
> </html>
>
>
> ----------------------------------------------------------------------
> *consuming page code:* <-- this is where task is defined in the
> UI:Repeat, so it is in scope
>
> <!DOCTYPE html
> PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:c="http://java.sun.com/jsp/jstl/core"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:socialpm="http://java.sun.com/jsf/composite/socialpm"
> xmlns:pretty="http://ocpsoft.com/prettyfaces"
> xmlns:ui="http://java.sun.com/jsf/facelets" xml:lang="en"
lang="en">
>
> <ui:composition>
> <h:form id="tasksForm">
> <c:if test="#{empty currentStoryBean.story.tasks}">
> <div class="m5">This story has no tasks. That could be a problem
> later...</div>
> </c:if>
>
> <ui:repeat value="#{currentStoryBean.story.tasks}"
var="task">
> <socialpm:taskBlock task="#{task}"
story="#{currentStoryBean.story}"
> members="#{currentProjectBean.project.activeMembers}"
> disabled="#{!authorizationBean.isMember or
> !currentStoryBean.story.open}"
> deletable="true" styleClass="m5t" refreshOnSave="false"
/>
> </ui:repeat>
> </h:form>
> </ui:composition>
> </html>
>
>
>
>
> On Sat, 2009-09-05 at 15:23 -0400, Andy Schwartz wrote:
>> Hey Lincoln -
>>
>> Lincoln Baxter, III wrote:
>> > First, please let me know if there is a better place to ask JSF
>> Dev > related questions.
>> >
>>
>> I suppose the Mojarra dev list might be the right place for
>> implementation questions:
>>
>> https://javaserverfaces.dev.java.net/mailinglists.html
>>
>> Though personally I am fine with you asking here. :-)
>>
>> Could you send along your composite component implementation (and
>> perhaps a snippet from the consuming page)? Just want to make sure
>> I understand the use case.
>>
>> Andy
>>
>>
> --
> *Lincoln Baxter, III*
> Co-Founder of OcpSoft <http://ocpsoft.com>
> Author of PrettyFaces <http://ocpsoft.com/prettyfaces> URL Rewriting
> for JSF
>
>
6:08 a.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Yep, that's what is happening.
YOU, sirs, are good.
Andy and Ryan both nailed it.
Thank you. This needs to be put in a good place where people will find
it, if it is not already. I searched for it in the PDLdoc but only found
a reference to parent in the index, and not to this effect. I'm not sure
most people would think to go through the parent, since EL is usually a
direct reference to the object immediately at hand.
Perhaps in the "Nesting of composite components" section?
https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/facelets/inde...
On Tue, 2009-09-08 at 09:59 -0700, Ryan Lubke wrote:
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Author of PrettyFaces URL Rewriting for JSF
6:33 a.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
One more issue I'd like to bring up: it appears that when using
<f:valueChangeListener action="..." /> the value of the object provided
has not yet been updated in the model, hence, the value is the old
value, not the new value.
When using <f:actionListener> on the button submitting the values, the
new value is populated into the model instead... which is the behavior I
would expect.
Pardon the probably obvious question...
Is there an contract with valueChangeListeners that states they fire
before model updates? I see in the spec that it fires: "when a new local
value has been created, and has passed all validations," but nothing
about if the model has been updated or not.
--Lincoln
On Tue, 2009-09-08 at 09:59 -0700, Ryan Lubke wrote:
On 9/7/09 6:06 PM, Andy Schwartz wrote:
> Thanks Lincoln. I haven't had time to debug this, but I have a theory
> about what might be happening. In your sample:
>
>> <a:editText value="#{cc.attrs.task.text}"
>> rendered="#{!cc.attrs.disabled}">
>> *<f:actionListener for="submit"
>> action="#{taskController.saveTaskAjax(cc.attrs.story,
>> cc.attrs.task)}" /> *
>> </a:editText>
>
> We expect "cc" to resolve to the containing composite component (ie.
> to the <socialpm:taskBlock> component). I wouldn't be surprised if
> what is actually happening is that "cc" is being resolved to the
> <a:editText> composite component instead.
Yep, that's what is happening.
> One reason why I suspect this might be happening is that I know that
> Ryan has investigated/resolved similar problems not too long ago.
The problem we resolved was the passing of #{cc.attrs} attributes
between nested composite components.
For this case, the spec recommends using cc.parent.attrs.story and
cc.parent.attrs.task, where parent resolves
to the nearest composite component parent of the current composite
component.
> Another reason why I am suspicious about this is because we have faced
> similar issues in our own (ADF Faces) declarative component solution.
> This stuff can get tricky. :-)
>
> Hey Ryan -
>
> Does this problem look familiar? Any thoughts on this?
>
> Andy
>
> Lincoln Baxter, III wrote:
>> Hey Andy, here you go:
>>
>> In the mean time I'm going to sign up for the dev lists.
>>
>> ----------------------------------------------------------------------
>> Using:
>> <f:actionListener for="submit"
>> action="*#{taskController.saveTaskAjax(cc.attrs.story,
>> cc.attrs.task)}*" />
>>
>> *#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}* =
>> null values passed to method
>> *#{taskController.saveTaskAjax(currentStoryBean.story, task)}* =
>> correct values resolved, assuming currentStoryBean.story and task
>> are both in the EL/page scope somewhere.
>>
>>
>> ----------------------------------------------------------------------
>> *CC Impl:*
>>
>>
>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>> <html xmlns="http://www.w3.org/1999/xhtml"
>> xmlns:h="http://java.sun.com/jsf/html"
>> xmlns:f="http://java.sun.com/jsf/core"
>> xmlns:a="http://java.sun.com/jsf/composite/ajax"
>> xmlns:cc="http://java.sun.com/jsf/composite">
>> <cc:interface>
>> <cc:attribute name="story" required="true"
type="Object" />
>> <cc:attribute name="task" required="true"
type="Object" />
>> <cc:attribute name="disabled" required="false"
type="Boolean"
>> default="false" />
>> <cc:insertChildren />
>> </cc:interface>
>>
>> <cc:implementation>
>> <h:outputStylesheet name="socialpm/socialpm.css" />
>> <h:panelGroup id="taskBlock" layout="block"
class="box-bordered p5
>> #{cc.attrs.styleClass} taskBlock_#{cc.attrs.task.status}"
>> style="#{cc.attrs.style}">
>>
>> <div class="m5l" style="margin-right: 25px;" >
>> <h:outputText value="#{cc.attrs.task.text}"
>> rendered="#{cc.attrs.disabled}"/>
>> <a:editText value="#{cc.attrs.task.text}"
>> rendered="#{!cc.attrs.disabled}">
>> *<f:actionListener for="submit"
>> action="#{taskController.saveTaskAjax(cc.attrs.story,
>> cc.attrs.task)}" /> *
>> </a:editText>
>> </div>
>> </cc:implementation>
>> </html>
>>
>>
>> ----------------------------------------------------------------------
>> *consuming page code:* <-- this is where task is defined in the
>> UI:Repeat, so it is in scope
>>
>> <!DOCTYPE html
>> PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>> <html xmlns="http://www.w3.org/1999/xhtml"
>> xmlns:c="http://java.sun.com/jsp/jstl/core"
>> xmlns:f="http://java.sun.com/jsf/core"
>> xmlns:h="http://java.sun.com/jsf/html"
>> xmlns:socialpm="http://java.sun.com/jsf/composite/socialpm"
>> xmlns:pretty="http://ocpsoft.com/prettyfaces"
>> xmlns:ui="http://java.sun.com/jsf/facelets" xml:lang="en"
lang="en">
>>
>> <ui:composition>
>> <h:form id="tasksForm">
>> <c:if test="#{empty currentStoryBean.story.tasks}">
>> <div class="m5">This story has no tasks. That could be a problem
>> later...</div>
>> </c:if>
>>
>> <ui:repeat value="#{currentStoryBean.story.tasks}"
var="task">
>> <socialpm:taskBlock task="#{task}"
story="#{currentStoryBean.story}"
>> members="#{currentProjectBean.project.activeMembers}"
>> disabled="#{!authorizationBean.isMember or
>> !currentStoryBean.story.open}"
>> deletable="true" styleClass="m5t"
refreshOnSave="false" />
>> </ui:repeat>
>> </h:form>
>> </ui:composition>
>> </html>
>>
>>
>>
>>
>> On Sat, 2009-09-05 at 15:23 -0400, Andy Schwartz wrote:
>>> Hey Lincoln -
>>>
>>> Lincoln Baxter, III wrote:
>>> > First, please let me know if there is a better place to ask JSF
>>> Dev > related questions.
>>> >
>>>
>>> I suppose the Mojarra dev list might be the right place for
>>> implementation questions:
>>>
>>> https://javaserverfaces.dev.java.net/mailinglists.html
>>>
>>> Though personally I am fine with you asking here. :-)
>>>
>>> Could you send along your composite component implementation (and
>>> perhaps a snippet from the consuming page)? Just want to make sure
>>> I understand the use case.
>>>
>>> Andy
>>>
>>>
>> --
>> *Lincoln Baxter, III*
>> Co-Founder of OcpSoft <http://ocpsoft.com>
>> Author of PrettyFaces <http://ocpsoft.com/prettyfaces> URL Rewriting
>> for JSF
>>
>>
>
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Author of PrettyFaces URL Rewriting for JSF
6:35 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On Wed, Sep 9, 2009 at 12:33 AM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
One more issue I'd like to bring up: it appears that when using
<f:valueChangeListener action="..." /> the value of the object provided
has
not yet been updated in the model, hence, the value is the old value, not
the new value.
When using <f:actionListener> on the button submitting the values, the new
value is populated into the model instead... which is the behavior I would
expect.
Pardon the probably obvious question...
Is there an contract with valueChangeListeners that states they fire before
model updates? I see in the spec that it fires: "when a new local value has
been created, and has passed all validations," but nothing about if the
model has been updated or not.
They're fired after the Process Validations phase (or Apply Request Values
if immediate=true), which always occurs before the Update Model phase. The
idea is that the input must be in a valid state before the model is updated.
--Lincoln
On Tue, 2009-09-08 at 09:59 -0700, Ryan Lubke wrote:
On 9/7/09 6:06 PM, Andy Schwartz wrote:
> Thanks Lincoln. I haven't had time to debug this, but I have a theory
> about what might be happening. In your sample:
>
>> <a:editText value="#{cc.attrs.task.text}"
>> rendered="#{!cc.attrs.disabled}">
>> *<f:actionListener for="submit"
>> action="#{taskController.saveTaskAjax(cc.attrs.story,
>> cc.attrs.task)}" /> *
>> </a:editText>
>
> We expect "cc" to resolve to the containing composite component (ie.
> to the <socialpm:taskBlock> component). I wouldn't be surprised if
> what is actually happening is that "cc" is being resolved to the
> <a:editText> composite component instead.
Yep, that's what is happening.
> One reason why I suspect this might be happening is that I know that
> Ryan has investigated/resolved similar problems not too long ago.
The problem we resolved was the passing of #{cc.attrs} attributes
between nested composite components.
For this case, the spec recommends using cc.parent.attrs.story and
cc.parent.attrs.task, where parent resolves
to the nearest composite component parent of the current composite
component.
> Another reason why I am suspicious about this is because we have faced
> similar issues in our own (ADF Faces) declarative component solution.
> This stuff can get tricky. :-)
>
> Hey Ryan -
>
> Does this problem look familiar? Any thoughts on this?
>
> Andy
>
> Lincoln Baxter, III wrote:
>> Hey Andy, here you go:
>>
>> In the mean time I'm going to sign up for the dev lists.
>>
>> ----------------------------------------------------------------------
>> Using:
>> <f:actionListener for="submit"
>> action="*#{taskController.saveTaskAjax(cc.attrs.story,
>> cc.attrs.task)}*" />
>>
>> *#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}* =
>> null values passed to method
>> *#{taskController.saveTaskAjax(currentStoryBean.story, task)}* =
>> correct values resolved, assuming currentStoryBean.story and task
>> are both in the EL/page scope somewhere.
>>
>>
>> ----------------------------------------------------------------------
>> *CC Impl:*
>>
>>
>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>> <html xmlns="http://www.w3.org/1999/xhtml"
>> xmlns:h="http://java.sun.com/jsf/html"
>> xmlns:f="http://java.sun.com/jsf/core"
>> xmlns:a="http://java.sun.com/jsf/composite/ajax"
>> xmlns:cc="http://java.sun.com/jsf/composite">
>> <cc:interface>
>> <cc:attribute name="story" required="true"
type="Object" />
>> <cc:attribute name="task" required="true"
type="Object" />
>> <cc:attribute name="disabled" required="false"
type="Boolean"
>> default="false" />
>> <cc:insertChildren />
>> </cc:interface>
>>
>> <cc:implementation>
>> <h:outputStylesheet name="socialpm/socialpm.css" />
>> <h:panelGroup id="taskBlock" layout="block"
class="box-bordered p5
>> #{cc.attrs.styleClass} taskBlock_#{cc.attrs.task.status}"
>> style="#{cc.attrs.style}">
>>
>> <div class="m5l" style="margin-right: 25px;" >
>> <h:outputText value="#{cc.attrs.task.text}"
>> rendered="#{cc.attrs.disabled}"/>
>> <a:editText value="#{cc.attrs.task.text}"
>> rendered="#{!cc.attrs.disabled}">
>> *<f:actionListener for="submit"
>> action="#{taskController.saveTaskAjax(cc.attrs.story,
>> cc.attrs.task)}" /> *
>> </a:editText>
>> </div>
>> </cc:implementation>
>> </html>
>>
>>
>> ----------------------------------------------------------------------
>> *consuming page code:* <-- this is where task is defined in the
>> UI:Repeat, so it is in scope
>>
>> <!DOCTYPE html
>> PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>> <html xmlns="http://www.w3.org/1999/xhtml"
>> xmlns:c="http://java.sun.com/jsp/jstl/core"
>> xmlns:f="http://java.sun.com/jsf/core"
>> xmlns:h="http://java.sun.com/jsf/html"
>> xmlns:socialpm="http://java.sun.com/jsf/composite/socialpm"
>> xmlns:pretty="http://ocpsoft.com/prettyfaces"
>> xmlns:ui="http://java.sun.com/jsf/facelets" xml:lang="en"
lang="en">
>>
>> <ui:composition>
>> <h:form id="tasksForm">
>> <c:if test="#{empty currentStoryBean.story.tasks}">
>> <div class="m5">This story has no tasks. That could be a
problem
>> later...</div>
>> </c:if>
>>
>> <ui:repeat value="#{currentStoryBean.story.tasks}"
var="task">
>> <socialpm:taskBlock task="#{task}"
story="#{currentStoryBean.story}"
>> members="#{currentProjectBean.project.activeMembers}"
>> disabled="#{!authorizationBean.isMember or
>> !currentStoryBean.story.open}"
>> deletable="true" styleClass="m5t"
refreshOnSave="false" />
>> </ui:repeat>
>> </h:form>
>> </ui:composition>
>> </html>
>>
>>
>>
>>
>> On Sat, 2009-09-05 at 15:23 -0400, Andy Schwartz wrote:
>>> Hey Lincoln -
>>>
>>> Lincoln Baxter, III wrote:
>>> > First, please let me know if there is a better place to ask JSF
>>> Dev > related questions.
>>> >
>>>
>>> I suppose the Mojarra dev list might be the right place for
>>> implementation questions:
>>>
>>> https://javaserverfaces.dev.java.net/mailinglists.html
>>>
>>> Though personally I am fine with you asking here. :-)
>>>
>>> Could you send along your composite component implementation (and
>>> perhaps a snippet from the consuming page)? Just want to make sure
>>> I understand the use case.
>>>
>>> Andy
>>>
>>>
>> --
>> *Lincoln Baxter, III*
>> Co-Founder of OcpSoft <http://ocpsoft.com>
>> Author of PrettyFaces <http://ocpsoft.com/prettyfaces> URL Rewriting
>> for JSF
>>
>>
>
--
*Lincoln Baxter, III*
Co-Founder of OcpSoft <http://ocpsoft.com>
Author of PrettyFaces <http://ocpsoft.com/prettyfaces> URL Rewriting for
JSF
7:04 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On Wed, Sep 9, 2009 at 12:35 PM, Kito Mann <kito.mann(a)virtua.com> wrote:
On Wed, Sep 9, 2009 at 12:33 AM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
> One more issue I'd like to bring up: it appears that when using
> <f:valueChangeListener action="..." /> the value of the object
provided has
> not yet been updated in the model, hence, the value is the old value, not
> the new value.
>
> When using <f:actionListener> on the button submitting the values, the new
> value is populated into the model instead... which is the behavior I would
> expect.
>
> Pardon the probably obvious question...
>
> Is there an contract with valueChangeListeners that states they fire
> before model updates? I see in the spec that it fires: "when a new local
> value has been created, and has passed all validations," but nothing about
> if the model has been updated or not.
>
They're fired after the Process Validations phase (or Apply Request Values
if immediate=true), which always occurs before the Update Model phase. The
idea is that the input must be in a valid state before the model is updated.
And that the value change listener is notified of the intent to change the
model value, hence giving it a chance to block the update (or at least that
becomes a possible course of action).
-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
7:09 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Makes sense, perhaps some additional verbiage to that point would be apropos. Ill add a
tracker for a pdl doc enhancement.
Thanks.
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Dan Allen <dan.j.allen(a)gmail.com>
Date: Wed, 9 Sep 2009 13:04:25
To: <jsr-314-open(a)jcp.org>
Cc: <lincolnbaxter(a)gmail.com>
Subject: Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On Wed, Sep 9, 2009 at 12:35 PM, Kito Mann <kito.mann(a)virtua.com> wrote:
On Wed, Sep 9, 2009 at 12:33 AM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
> One more issue I'd like to bring up: it appears that when using
> <f:valueChangeListener action="..." /> the value of the object
provided has
> not yet been updated in the model, hence, the value is the old value, not
> the new value.
>
> When using <f:actionListener> on the button submitting the values, the new
> value is populated into the model instead... which is the behavior I would
> expect.
>
> Pardon the probably obvious question...
>
> Is there an contract with valueChangeListeners that states they fire
> before model updates? I see in the spec that it fires: "when a new local
> value has been created, and has passed all validations," but nothing about
> if the model has been updated or not.
>
They're fired after the Process Validations phase (or Apply Request Values
if immediate=true), which always occurs before the Update Model phase. The
idea is that the input must be in a valid state before the model is updated.
And that the value change listener is notified of the intent to change the
model value, hence giving it a chance to block the update (or at least that
becomes a possible course of action).
-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
12:34 a.m.
New subject: [jsr-314-open] #{cc} semantics
Ryan, All -
Breaking this topic off into a separate thread, though I am impressed
with the length of the "<h:dataTable> binding vs. ui:repeat" thread. :-)
Ryan Lubke wrote:
On 9/7/09 6:06 PM, Andy Schwartz wrote:
> Thanks Lincoln. I haven't had time to debug this, but I have a
> theory about what might be happening. In your sample:
>
>> <a:editText value="#{cc.attrs.task.text}"
>> rendered="#{!cc.attrs.disabled}">
>> *<f:actionListener for="submit"
>> action="#{taskController.saveTaskAjax(cc.attrs.story,
>> cc.attrs.task)}" /> *
>> </a:editText>
>
> We expect "cc" to resolve to the containing composite component (ie.
> to the <socialpm:taskBlock> component). I wouldn't be surprised if
> what is actually happening is that "cc" is being resolved to the
> <a:editText> composite component instead.
Yep, that's what is happening.
> One reason why I suspect this might be happening is that I know that
> Ryan has investigated/resolved similar problems not too long ago.
The problem we resolved was the passing of #{cc.attrs} attributes
between nested composite components.
For this case, the spec recommends using cc.parent.attrs.story and
cc.parent.attrs.task, where parent resolves
to the nearest composite component parent of the current composite
component.
I am concerned about this behavior. It isn't clear to me whether the
spec is explicit about this behavior, or whether this is something that
happens to fall out of the implementation. Either way, the current
behavior seems counterintuitive to me, and, well... wrong.
My feeling is that when a composite component author uses a #{cc}
expression in a composite component implementation, eg:
<composite:implementation>
<h:outputText value="#{cc.attrs.value}">
</composite:implementation>
The correct behavior (the behavior expected by the composite component
author) is to resolve the #{cc} expression relative to where the
expression is defined - not relative to where it happens to end up in
the component tree. So, for example, I believe that these three uses of
the #{cc.attrs.value} expression should all evaluate to the same value:
<composite:implementation>
<!-- 1. Expression directly in the implementation -->
<h:outputText value="#{cc.attrs.value}">
<!-- 2. Expression in non-composite component facet -->
<bar:someJavaComposite>
<f:facet name="someFacet">
<h:outputText value="#{cc.attrs.value}">
</f:facet>
</bar:someJavaComponent>
<!-- 3. Expression in composite component facet -->
<foo:someCompositeComponent>
<f:facet name="someFacet">
<h:outputText value="#{cc.attrs.value}">
</f:facet>
</foo:someCompositeComponent>
</composite:implementation>
The fact that the #{cc.attrs.value} expression evaluates the same in
cases #1 and #2 but not in case #3 is non-obvious and is going to be
confusing for our users. The fact that Lincoln and I were confused
about this is a good indication that others will be as well.
I am not happy with the work around of using #cc.parent.attrs, since
this means that:
1. The user must recognize that the component in question is a composite
component and code the expression differently. While at the moment it
is fairly easy to determine whether a particular component is a
composite or not (by looking at the namespace declaration), I think that
we should strive to blur these lines rather than reinforce them. For
example, I would like to see the ability to define a single tag library
that consists of both composite and non-composite components, making the
choice of component implementation more transparent to the user.
2. Once the user has coded the expression in a composite
component-specific way, this introduces a dependency on the fact that
the component in question is a composite component - a dependency that
shouldn't be necessary for this particular case. Such dependencies
inhibit flexibility. If in the future the provider of the composite
component decides to switch to a Java-based component, this will break
any code (or EL expression) that assumes that the component is a
composite. We should keep such dependencies to a minimum.
3. This also introduces a subtle dependency on the composite component's
implementation. What if the composite component implementation passes
the expression along to yet another nested composite component? Does
the user now need to specify an expression that pops out multiple levels
of parents?
While it is certainly trickier to deal with from an implementation
perspective, I believe that it is very important that we re-consider the
current behavior and consider spec'ing that #{cc} expressions always
resolve relative to the context in which they are defined. I feel that
the current behavior violates the principle of least surprise (both
Lincoln and I were surprised) and also breaks encapsulation (ie.
introduces implementation-specific dependencies).
Leaving aside questions of how we might implement my preferred behavior
for the moment... Does anyone have comments on which behavior makes
sense from a spec/end user perspective?
Andy
1:53 a.m.
New subject: [jsr-314-open] #{cc} semantics
Well Andy.....
I agree 100% with you.
Thanks,
Ken
Andy Schwartz wrote:
Ryan, All -
Breaking this topic off into a separate thread, though I am impressed
with the length of the "<h:dataTable> binding vs. ui:repeat" thread. :-)
Ryan Lubke wrote:
> On 9/7/09 6:06 PM, Andy Schwartz wrote:
>> Thanks Lincoln. I haven't had time to debug this, but I have a
>> theory about what might be happening. In your sample:
>>
>>> <a:editText value="#{cc.attrs.task.text}"
>>> rendered="#{!cc.attrs.disabled}">
>>> *<f:actionListener for="submit"
>>> action="#{taskController.saveTaskAjax(cc.attrs.story,
>>> cc.attrs.task)}" /> *
>>> </a:editText>
>>
>> We expect "cc" to resolve to the containing composite component (ie.
>> to the <socialpm:taskBlock> component). I wouldn't be surprised if
>> what is actually happening is that "cc" is being resolved to the
>> <a:editText> composite component instead.
> Yep, that's what is happening.
>> One reason why I suspect this might be happening is that I know that
>> Ryan has investigated/resolved similar problems not too long ago.
> The problem we resolved was the passing of #{cc.attrs} attributes
> between nested composite components.
> For this case, the spec recommends using cc.parent.attrs.story and
> cc.parent.attrs.task, where parent resolves
> to the nearest composite component parent of the current composite
> component.
I am concerned about this behavior. It isn't clear to me whether the
spec is explicit about this behavior, or whether this is something
that happens to fall out of the implementation. Either way, the
current behavior seems counterintuitive to me, and, well... wrong.
My feeling is that when a composite component author uses a #{cc}
expression in a composite component implementation, eg:
<composite:implementation>
<h:outputText value="#{cc.attrs.value}">
</composite:implementation>
The correct behavior (the behavior expected by the composite component
author) is to resolve the #{cc} expression relative to where the
expression is defined - not relative to where it happens to end up in
the component tree. So, for example, I believe that these three uses
of the #{cc.attrs.value} expression should all evaluate to the same
value:
<composite:implementation>
<!-- 1. Expression directly in the implementation -->
<h:outputText value="#{cc.attrs.value}">
<!-- 2. Expression in non-composite component facet -->
<bar:someJavaComposite>
<f:facet name="someFacet">
<h:outputText value="#{cc.attrs.value}">
</f:facet>
</bar:someJavaComponent>
<!-- 3. Expression in composite component facet -->
<foo:someCompositeComponent>
<f:facet name="someFacet">
<h:outputText value="#{cc.attrs.value}">
</f:facet>
</foo:someCompositeComponent>
</composite:implementation>
The fact that the #{cc.attrs.value} expression evaluates the same in
cases #1 and #2 but not in case #3 is non-obvious and is going to be
confusing for our users. The fact that Lincoln and I were confused
about this is a good indication that others will be as well.
I am not happy with the work around of using #cc.parent.attrs, since
this means that:
1. The user must recognize that the component in question is a
composite component and code the expression differently. While at the
moment it is fairly easy to determine whether a particular component
is a composite or not (by looking at the namespace declaration), I
think that we should strive to blur these lines rather than reinforce
them. For example, I would like to see the ability to define a single
tag library that consists of both composite and non-composite
components, making the choice of component implementation more
transparent to the user.
2. Once the user has coded the expression in a composite
component-specific way, this introduces a dependency on the fact that
the component in question is a composite component - a dependency that
shouldn't be necessary for this particular case. Such dependencies
inhibit flexibility. If in the future the provider of the composite
component decides to switch to a Java-based component, this will break
any code (or EL expression) that assumes that the component is a
composite. We should keep such dependencies to a minimum.
3. This also introduces a subtle dependency on the composite
component's implementation. What if the composite component
implementation passes the expression along to yet another nested
composite component? Does the user now need to specify an expression
that pops out multiple levels of parents?
While it is certainly trickier to deal with from an implementation
perspective, I believe that it is very important that we re-consider
the current behavior and consider spec'ing that #{cc} expressions
always resolve relative to the context in which they are defined. I
feel that the current behavior violates the principle of least
surprise (both Lincoln and I were surprised) and also breaks
encapsulation (ie. introduces implementation-specific dependencies).
Leaving aside questions of how we might implement my preferred
behavior for the moment... Does anyone have comments on which
behavior makes sense from a spec/end user perspective?
Andy
2:44 a.m.
New subject: [jsr-314-open] #{cc} semantics
On 09/15/2009 03:34 PM, Andy Schwartz wrote:
Ryan, All -
Breaking this topic off into a separate thread, though I am impressed
with the length of the "<h:dataTable> binding vs. ui:repeat" thread. :-)
Ryan Lubke wrote:
> On 9/7/09 6:06 PM, Andy Schwartz wrote:
>> Thanks Lincoln. I haven't had time to debug this, but I have a
>> theory about what might be happening. In your sample:
>>
>>> <a:editText value="#{cc.attrs.task.text}"
>>> rendered="#{!cc.attrs.disabled}">
>>> *<f:actionListener for="submit"
>>> action="#{taskController.saveTaskAjax(cc.attrs.story,
>>> cc.attrs.task)}" /> *
>>> </a:editText>
>>
>> We expect "cc" to resolve to the containing composite component (ie.
>> to the <socialpm:taskBlock> component). I wouldn't be surprised if
>> what is actually happening is that "cc" is being resolved to the
>> <a:editText> composite component instead.
> Yep, that's what is happening.
>> One reason why I suspect this might be happening is that I know that
>> Ryan has investigated/resolved similar problems not too long ago.
> The problem we resolved was the passing of #{cc.attrs} attributes
> between nested composite components.
> For this case, the spec recommends using cc.parent.attrs.story and
> cc.parent.attrs.task, where parent resolves
> to the nearest composite component parent of the current composite
> component.
I am concerned about this behavior. It isn't clear to me whether the
spec is explicit about this behavior, or whether this is something
that happens to fall out of the implementation. Either way, the
current behavior seems counterintuitive to me, and, well... wrong.
My feeling is that when a composite component author uses a #{cc}
expression in a composite component implementation, eg:
<composite:implementation>
<h:outputText value="#{cc.attrs.value}">
</composite:implementation>
The correct behavior (the behavior expected by the composite component
author) is to resolve the #{cc} expression relative to where the
expression is defined - not relative to where it happens to end up in
the component tree. So, for example, I believe that these three uses
of the #{cc.attrs.value} expression should all evaluate to the same
value:
<composite:implementation>
<!-- 1. Expression directly in the implementation -->
<h:outputText value="#{cc.attrs.value}">
<!-- 2. Expression in non-composite component facet -->
<bar:someJavaComposite>
<f:facet name="someFacet">
<h:outputText value="#{cc.attrs.value}">
</f:facet>
</bar:someJavaComponent>
<!-- 3. Expression in composite component facet -->
<foo:someCompositeComponent>
<f:facet name="someFacet">
<h:outputText value="#{cc.attrs.value}">
</f:facet>
</foo:someCompositeComponent>
</composite:implementation>
The fact that the #{cc.attrs.value} expression evaluates the same in
cases #1 and #2 but not in case #3 is non-obvious and is going to be
confusing for our users. The fact that Lincoln and I were confused
about this is a good indication that others will be as well.
Complete agree with
that point. Especially in the case of using
third-party libraries, where vendor could decide to change component
implementation from java to composite or vice versa that can break other
composite components depended of the original library.
I am not happy with the work around of using #cc.parent.attrs, since
this means that:
1. The user must recognize that the component in question is a
composite component and code the expression differently. While at the
moment it is fairly easy to determine whether a particular component
is a composite or not (by looking at the namespace declaration), I
think that we should strive to blur these lines rather than reinforce
them. For example, I would like to see the ability to define a single
tag library that consists of both composite and non-composite
components, making the choice of component implementation more
transparent to the user.
Yes, that is obvious wishlist for component library
vendors.
Unfortunately, it is not possible now to mix Java and composite
components in the same library ( at least, this is not trivial to do in
the implementation-independent way.
2. Once the user has coded the expression in a composite
component-specific way, this introduces a dependency on the fact that
the component in question is a composite component - a dependency that
shouldn't be necessary for this particular case. Such dependencies
inhibit flexibility. If in the future the provider of the composite
component decides to switch to a Java-based component, this will break
any code (or EL expression) that assumes that the component is a
composite. We should keep such dependencies to a minimum.
3. This also introduces a subtle dependency on the composite
component's implementation. What if the composite component
implementation passes the expression along to yet another nested
composite component? Does the user now need to specify an expression
that pops out multiple levels of parents?
While it is certainly trickier to deal with from an implementation
perspective, I believe that it is very important that we re-consider
the current behavior and consider spec'ing that #{cc} expressions
always resolve relative to the context in which they are defined. I
feel that the current behavior violates the principle of least
surprise (both Lincoln and I were surprised) and also breaks
encapsulation (ie. introduces implementation-specific dependencies).
Leaving aside questions of how we might implement my preferred
behavior for the moment... Does anyone have comments on which
behavior makes sense from a spec/end user perspective?
Andy
9:23 p.m.
New subject: [jsr-314-open] #{cc} semantics
+1.
Also...
1. The user must recognize that the component in question is a
composite
component and code the expression differently. While at the moment it is
fairly easy to determine whether a particular component is a composite or
not (by looking at the namespace declaration), I think that we should strive
to blur these lines rather than reinforce them.
Exactly. We don't want the page author to start discriminating between the
implementations of a component. That's dangerous.
Leaving aside questions of how we might implement my preferred behavior for
the moment... Does anyone have comments on which behavior makes
sense from
a spec/end user perspective?
The general goal should be to make composite components as indistinguishable
from formal Java-developed components as possible.
-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://www.google.com/profiles/dan.j.allen
6:49 a.m.
New subject: [jsr-314-open] #{cc} semantics
On Tue, 2009-09-15 at 18:34 -0400, Andy Schwartz wrote:
I feel that
the current behavior violates the principle of least surprise (both
Lincoln and I were surprised) and also breaks encapsulation (ie.
introduces implementation-specific dependencies).
Andy, I agree.
+1
In every other EL situation, values are rooted in the context within
which they were defined. I didn't give it too much thought at first, but
this would definitely be counter-intuitive.
This is probably stating the obvious, but I don't want to forget about
use case #4: passing as an attribute should also behave the same way
(see inline.)
<composite:implementation>
<!-- 1. Expression directly in the implementation -->
<h:outputText value="#{cc.attrs.value}">
<!-- 2. Expression in non-composite component facet -->
<bar:someJavaComposite>
<f:facet name="someFacet">
<h:outputText value="#{cc.attrs.value}">
</f:facet>
</bar:someJavaComponent>
<!-- 3. Expression in composite component facet -->
<foo:someCompositeComponent>
<f:facet name="someFacet">
<h:outputText value="#{cc.attrs.value}">
</f:facet>
</foo:someCompositeComponent>
<!-- 4. Expression in composite component attribute -->
<bar:someCompositeComponent value="#{cc.attrs.value}" />
</composite:implementation>
It boggles my mind thinking about how to go about implementing this, but
it needs to happen in order to, as Andy said, "adhere to the principle
of least surprise".
--Lincoln
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Author of PrettyFaces URL Rewriting for JSF
6:12 p.m.
New subject: [jsr-314-open] #{cc} semantics
+1
---
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99 http://twitter.com/jsfcentral
JSF 2 Seminar Oct 6th: http://www.regonline.com/jsf2seminar
JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
+1 203-404-4848 x3
On Tue, Sep 15, 2009 at 6:34 PM, Andy Schwartz <andy.schwartz(a)oracle.com>wrote:
Ryan, All -
Breaking this topic off into a separate thread, though I am impressed with
the length of the "<h:dataTable> binding vs. ui:repeat" thread. :-)
Ryan Lubke wrote:
> On 9/7/09 6:06 PM, Andy Schwartz wrote:
>
>> Thanks Lincoln. I haven't had time to debug this, but I have a theory
>> about what might be happening. In your sample:
>>
>> <a:editText value="#{cc.attrs.task.text}"
>>> rendered="#{!cc.attrs.disabled}">
>>> *<f:actionListener for="submit"
>>> action="#{taskController.saveTaskAjax(cc.attrs.story,
cc.attrs.task)}" /> *
>>> </a:editText>
>>>
>>
>> We expect "cc" to resolve to the containing composite component (ie.
to
>> the <socialpm:taskBlock> component). I wouldn't be surprised if what
is
>> actually happening is that "cc" is being resolved to the
<a:editText>
>> composite component instead.
>>
> Yep, that's what is happening.
>
>> One reason why I suspect this might be happening is that I know that Ryan
>> has investigated/resolved similar problems not too long ago.
>>
> The problem we resolved was the passing of #{cc.attrs} attributes between
> nested composite components.
> For this case, the spec recommends using cc.parent.attrs.story and
> cc.parent.attrs.task, where parent resolves
> to the nearest composite component parent of the current composite
> component.
>
I am concerned about this behavior. It isn't clear to me whether the spec
is explicit about this behavior, or whether this is something that happens
to fall out of the implementation. Either way, the current behavior seems
counterintuitive to me, and, well... wrong.
My feeling is that when a composite component author uses a #{cc}
expression in a composite component implementation, eg:
<composite:implementation>
<h:outputText value="#{cc.attrs.value}">
</composite:implementation>
The correct behavior (the behavior expected by the composite component
author) is to resolve the #{cc} expression relative to where the expression
is defined - not relative to where it happens to end up in the component
tree. So, for example, I believe that these three uses of the
#{cc.attrs.value} expression should all evaluate to the same value:
<composite:implementation>
<!-- 1. Expression directly in the implementation -->
<h:outputText value="#{cc.attrs.value}">
<!-- 2. Expression in non-composite component facet -->
<bar:someJavaComposite>
<f:facet name="someFacet">
<h:outputText value="#{cc.attrs.value}">
</f:facet>
</bar:someJavaComponent>
<!-- 3. Expression in composite component facet -->
<foo:someCompositeComponent>
<f:facet name="someFacet">
<h:outputText value="#{cc.attrs.value}">
</f:facet>
</foo:someCompositeComponent>
</composite:implementation>
The fact that the #{cc.attrs.value} expression evaluates the same in cases
#1 and #2 but not in case #3 is non-obvious and is going to be confusing for
our users. The fact that Lincoln and I were confused about this is a good
indication that others will be as well.
I am not happy with the work around of using #cc.parent.attrs, since this
means that:
1. The user must recognize that the component in question is a composite
component and code the expression differently. While at the moment it is
fairly easy to determine whether a particular component is a composite or
not (by looking at the namespace declaration), I think that we should strive
to blur these lines rather than reinforce them. For example, I would like
to see the ability to define a single tag library that consists of both
composite and non-composite components, making the choice of component
implementation more transparent to the user.
2. Once the user has coded the expression in a composite component-specific
way, this introduces a dependency on the fact that the component in question
is a composite component - a dependency that shouldn't be necessary for this
particular case. Such dependencies inhibit flexibility. If in the future
the provider of the composite component decides to switch to a Java-based
component, this will break any code (or EL expression) that assumes that the
component is a composite. We should keep such dependencies to a minimum.
3. This also introduces a subtle dependency on the composite component's
implementation. What if the composite component implementation passes the
expression along to yet another nested composite component? Does the user
now need to specify an expression that pops out multiple levels of parents?
While it is certainly trickier to deal with from an implementation
perspective, I believe that it is very important that we re-consider the
current behavior and consider spec'ing that #{cc} expressions always resolve
relative to the context in which they are defined. I feel that the current
behavior violates the principle of least surprise (both Lincoln and I were
surprised) and also breaks encapsulation (ie. introduces
implementation-specific dependencies).
Leaving aside questions of how we might implement my preferred behavior for
the moment... Does anyone have comments on which behavior makes sense from
a spec/end user perspective?
Andy
5396
days inactive
5405
days old
jsr-314-open-mirror@lists.jboss.org
13 comments
8 participants
participants (8)
-
Alaxander Smirnov -
Andy Schwartz -
Dan Allen -
Ken Paulsen -
Kito Mann -
Lincoln Baxter, III -
lincolnbaxter＠gmail.com
-
Ryan Lubke