You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Ganesh <ga...@j4fry.org> on 2009/05/13 20:06:10 UTC
[Fwd: Re: f:ajax not working inside composite components?]
Hi everybody who is involved with MyFaces 2.0,
have you seen this?
From this:
> <h:selectOneMenu id="menu"
> value="#{place.zoomIndex}"
> valueChangeListener="#{place.zoomChanged}"
> style="font-size:13px;font-family:Palatino">
>
> <f:selectItems value="#{places.zoomLevelItems}"/>
> *<f:ajax execute="@this" render="image"/>
> *
> </h:selectOneMenu>
,nested inside a ui:repeat and a composition, Mojarra creates this AJAX
request:
form form
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
3
javax.faces.ViewState -1363564553004911965:-1863826268811277742
javax.faces.behavior.event valueChange
javax.faces.partial.ajax true
javax.faces.partial.event change
javax.faces.partial.execute
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
javax.faces.partial.render
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
javax.faces.source
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
In the JSR-314 spec it says in table 14-1:
>>render - A space delimited list of client identifiers or one of the
keywords (Section 14.2.2 “Keywords”). These reference the components
that will be processed during the “render” phase of the request
processing lifecycle.<<
now, 'image' is definitely not a client identifier, but a component
identifier. And there is more! Andy Schwarz comments on this:
>>When specifying execute/render ids for <f:ajax>, the id resolution
behavior is similar to findComponent(). So, if you specify a relative
id, eg. "image", this should be resolved relative to the nearest naming
container. In your case, that would be the composite component. In order
to specify an absolute id, you would prefix the id with ":", eg.
":foo:mycompositecomp:image".<<
Both kinds of behaviour - resolving ids either relative to the nearest
naming container or prepending them with a ":" to mark them absolute -
cannot be found in the spec.
So, what do we do? Shall we follow Mojarras paths even if not covered by
the specs words? Or do purposely break application portability to adhere
to the specs?
Please comment on this.
Best regards,
Ganesh
P.S.: For the curious ones: The reason why Davids code doesn't work
because there is some bug in the decode processing of ui:repeat that
Ryan is currently fixing ...
-------- Original-Nachricht --------
Betreff: Re: f:ajax not working inside composite components?
Datum: Tue, 12 May 2009 14:39:58 -0700
Von: Ryan Lubke <Ry...@SUN.COM>
Antwort an: JSR 314 Open Mailing list <JS...@JCP.ORG>
An: JSR-314-OPEN@JCP.ORG
Referenzen:
<75...@mail.gmail.com>
<4A...@oracle.com>
<75...@mail.gmail.com>
On 5/12/09 2:17 PM, David Geary wrote:
> 2009/5/12 Andy Schwartz <andy.schwartz@oracle.com
> <ma...@oracle.com>>
>
> Hi David -
>
>
> Hi Andy,
>
> Thanks for responding.
>
> David Geary wrote On 5/12/2009 12:36 PM ET:
>> <h:selectOneMenu id="menu"
>> value="#{place.zoomIndex}"
>> valueChangeListener="#{place.zoomChanged}"
>> style="font-size:13px;font-family:Palatino">
>>
>> <f:selectItems value="#{places.zoomLevelItems}"/>
>> *<f:ajax execute="@this" render="image"/>
>> *
>> </h:selectOneMenu>
>
> This looks good to me.
>
>
> Yup. I thought that perhaps I was failing validation for some reason,
> so I added immediate="true" to the f:ajax tag, but it didn't fix the
> problem. :(
>
>> With FireBug, I've verified that a POST request is indeed executed
>> when I change the zoom level, and it appears that everything is in order:
>>
>> form form
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>> 3
>> javax.faces.ViewState -1363564553004911965:-1863826268811277742
>> javax.faces.behavior.event valueChange
>> javax.faces.partial.ajax true
>> javax.faces.partial.event change
>> javax.faces.partial.execute
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>> javax.faces.partial.render
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>> javax.faces.source
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>
> And the request payload looks right - seems like all of the
> necessary information is present. (Though, man, those
> auto-generated client ids sure are huge!)
>
>
> Yes, it looks right to me too.
>> I get a response back that looks like this:
>>
>> <?xml version="1.0" encoding="utf-8"?>
>> <partial-response><changes><update
>> id="javax.faces.ViewState"><![CDATA[1747337848471748955:2683565346534242854
>> ]]></update></changes></partial-response>
>>
>> However, with f:ajax, my value change listener is never invoked on
>> the server, so the menu doesn't update, even though I've specified
>> that the menu should go through the execute phase of the lifecycle.
>>
>> Does anyone know why my value change listener is not invoked? Am I
>> doing something wrong, or is this a bug?
>
> Seems like the execute portion of the lifecycle is not being
> invoked properly. I don't see anything wrong in your code - so I
> suspect there is a bug here.
>
>
> I put a phase listener in the app to monitor the lifecycle, and all
> six phases of the lifecycle are invoked, in the correct order when the
> ajax request is made, but my value change listener is still not
> invoked. It's interesting to note that when I remove the f:ajax tag,
> and add an onchange="submit()" attribute to the menu, my value change
> listener does get invoked, so it definitely seems like a bug to me. I
> can't think of any good reason for the difference in behavior between
> the Ajax and non-Ajax versions.
>
> It seems to me that the lifecycle is executing properly, but it's not
> processing my menu, even though I've got execute="@this", and that
> information is apparently correctly passed to the server.
>
> Is anyone from the RI team listening? Ryan? I can JAR up the app, and
> send it to interested parties. I'd really like to get this fixed so I
> can nail down this demo for JavaOne. It's a pretty cool demo, but it
> looses much of its appeal when it doesn't work.
Feel free to send it my way.
>
> Help!!
>>
>> btw, here are a couple of interesting datapoints:
>>
>> 1. I have breakpoints in jsf.ajax.request and jsf.ajax.response. The
>> request breakpoint is hit, but the response is not. The return status
>> for the response is 200, so there are apparently no errors.
>>
>> 2. I thought, from Jim Driscoll's blog about f:ajax, that we had to
>> specify client ids for execute and render, so I originally had this:
>>
>> <f:ajax execute="@this" render="#{cc.clientId}:image"/>
>>
>> But when I do that, I get this error...
>>
>> <f:ajax> contains an unknown id
>> 'j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image'
>>
>> ...when I load the page, even though that is the correct client id
>> (as evidenced from the request data above). Evidently, we're supposed
>> to use the component id and not the client id?
>
> When specifying execute/render ids for <f:ajax>, the id resolution
> behavior is similar to findComponent(). So, if you specify a
> relative id, eg. "image", this should be resolved relative to the
> nearest naming container. In your case, that would be the
> composite component. In order to specify an absolute id, you would
> prefix the id with ":", eg. ":foo:mycompositecomp:image".
>
>
> Ah, okay, I missed that in the docs. Thanks for the explanation.
>
>
> david
Re: [Fwd: Re: f:ajax not working inside composite components?]
Posted by Matthias Wessendorf <ma...@apache.org>.
On Thu, May 14, 2009 at 8:25 AM, Alexander Bell
<Al...@j4fry.org> wrote:
> Hi Matthias,
>
> I suppose Ganesh doesn't mean the bug of UIRepeat.
I got that, I was just wondering if they fix it right.
If there is a bug that is only fixed in the "RI version of Facelets"
we need to fix it too... If they port it back to the original version
of Facelets (which is under ASL), it is *much* easier to get the
fix back... that's all I was saying.
as said before, somewhat offtopic, but not unimportant...
-M
> We've implemented the ajax in that way that you have to use the client id
> (so the id of the HTML element) in "execute" and "render".
>
> Andy Schwartz wrote there's an extra colon possibility which you can add to
> an ID in "render" for an absolute ID.
> Relative ID: image
> Absolute ID: :myForm:myNamingContainer:image
> HTML ID:
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>
> So for me it makes sense to use the JSF ID which should be resolved relative
> to the nearest naming container --> we have to adjust our Ajax. In my
> opinion we should not use the HTML ID because it's tricky to put the HTML ID
> in "execute" or "render"
>
> regards alex
>
>
> 2009/5/13 Matthias Wessendorf <ma...@apache.org>
>>
>> On Wed, May 13, 2009 at 8:12 PM, Matthias Wessendorf <ma...@apache.org>
>> wrote:
>> >>
>> >> P.S.: For the curious ones: The reason why Davids code doesn't work
>> >> because
>> >> there is some bug in the decode processing of ui:repeat that Ryan is
>> >> currently fixing ...
>> >
>> > I read that, but I guess they just fix it in their internal repo,
>> > not in the REAL facelets that has the *right* license, right ?!
>>
>> ui:repeat has some issue:
>>
>> https://issues.apache.org/jira/browse/TRINIDAD-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707051#action_12707051
>>
>> (I know this is kinda offtopic)
>>
>> -M
>>
>>
>> >
>> >
>> >
>> >>
>> >> -------- Original-Nachricht --------
>> >> Betreff: Re: f:ajax not working inside composite components?
>> >> Datum: Tue, 12 May 2009 14:39:58 -0700
>> >> Von: Ryan Lubke <Ry...@SUN.COM>
>> >> Antwort an: JSR 314 Open Mailing list <JS...@JCP.ORG>
>> >> An: JSR-314-OPEN@JCP.ORG
>> >> Referenzen:
>> >> <75...@mail.gmail.com>
>> >> <4A...@oracle.com>
>> >> <75...@mail.gmail.com>
>> >>
>> >>
>> >>
>> >> On 5/12/09 2:17 PM, David Geary wrote:
>> >>>
>> >>> 2009/5/12 Andy Schwartz <andy.schwartz@oracle.com
>> >>> <ma...@oracle.com>>
>> >>>
>> >>> Hi David -
>> >>>
>> >>>
>> >>> Hi Andy,
>> >>>
>> >>> Thanks for responding.
>> >>>
>> >>> David Geary wrote On 5/12/2009 12:36 PM ET:
>> >>>>
>> >>>> <h:selectOneMenu id="menu"
>> >>>> value="#{place.zoomIndex}"
>> >>>> valueChangeListener="#{place.zoomChanged}"
>> >>>> style="font-size:13px;font-family:Palatino">
>> >>>>
>> >>>> <f:selectItems value="#{places.zoomLevelItems}"/>
>> >>>> *<f:ajax execute="@this" render="image"/>
>> >>>> *
>> >>>> </h:selectOneMenu>
>> >>>
>> >>> This looks good to me.
>> >>>
>> >>>
>> >>> Yup. I thought that perhaps I was failing validation for some reason,
>> >>> so I
>> >>> added immediate="true" to the f:ajax tag, but it didn't fix the
>> >>> problem. :(
>> >>>
>> >>>> With FireBug, I've verified that a POST request is indeed executed
>> >>>> when I
>> >>>> change the zoom level, and it appears that everything is in order:
>> >>>>
>> >>>> form form
>> >>>>
>> >>>>
>> >>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>> >>>> 3
>> >>>> javax.faces.ViewState -1363564553004911965:-1863826268811277742
>> >>>> javax.faces.behavior.event valueChange
>> >>>> javax.faces.partial.ajax true
>> >>>> javax.faces.partial.event change
>> >>>> javax.faces.partial.execute
>> >>>>
>> >>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>> >>>> javax.faces.partial.render
>> >>>>
>> >>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>> >>>> javax.faces.source
>> >>>>
>> >>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>> >>>
>> >>> And the request payload looks right - seems like all of the
>> >>> necessary information is present. (Though, man, those
>> >>> auto-generated client ids sure are huge!)
>> >>>
>> >>>
>> >>> Yes, it looks right to me too.
>> >>>>
>> >>>> I get a response back that looks like this:
>> >>>>
>> >>>> <?xml version="1.0" encoding="utf-8"?>
>> >>>> <partial-response><changes><update
>> >>>>
>> >>>> id="javax.faces.ViewState"><![CDATA[1747337848471748955:2683565346534242854
>> >>>> ]]></update></changes></partial-response>
>> >>>>
>> >>>> However, with f:ajax, my value change listener is never invoked on
>> >>>> the
>> >>>> server, so the menu doesn't update, even though I've specified that
>> >>>> the menu
>> >>>> should go through the execute phase of the lifecycle.
>> >>>>
>> >>>> Does anyone know why my value change listener is not invoked? Am I
>> >>>> doing
>> >>>> something wrong, or is this a bug?
>> >>>
>> >>> Seems like the execute portion of the lifecycle is not being
>> >>> invoked properly. I don't see anything wrong in your code - so I
>> >>> suspect there is a bug here.
>> >>>
>> >>>
>> >>> I put a phase listener in the app to monitor the lifecycle, and all
>> >>> six
>> >>> phases of the lifecycle are invoked, in the correct order when the
>> >>> ajax
>> >>> request is made, but my value change listener is still not invoked.
>> >>> It's
>> >>> interesting to note that when I remove the f:ajax tag, and add an
>> >>> onchange="submit()" attribute to the menu, my value change listener
>> >>> does get
>> >>> invoked, so it definitely seems like a bug to me. I can't think of any
>> >>> good
>> >>> reason for the difference in behavior between the Ajax and non-Ajax
>> >>> versions.
>> >>>
>> >>> It seems to me that the lifecycle is executing properly, but it's not
>> >>> processing my menu, even though I've got execute="@this", and that
>> >>> information is apparently correctly passed to the server.
>> >>>
>> >>> Is anyone from the RI team listening? Ryan? I can JAR up the app, and
>> >>> send
>> >>> it to interested parties. I'd really like to get this fixed so I can
>> >>> nail
>> >>> down this demo for JavaOne. It's a pretty cool demo, but it looses
>> >>> much of
>> >>> its appeal when it doesn't work.
>> >>
>> >> Feel free to send it my way.
>> >>>
>> >>> Help!!
>> >>>>
>> >>>> btw, here are a couple of interesting datapoints:
>> >>>>
>> >>>> 1. I have breakpoints in jsf.ajax.request and jsf.ajax.response. The
>> >>>> request breakpoint is hit, but the response is not. The return status
>> >>>> for
>> >>>> the response is 200, so there are apparently no errors.
>> >>>>
>> >>>> 2. I thought, from Jim Driscoll's blog about f:ajax, that we had to
>> >>>> specify client ids for execute and render, so I originally had this:
>> >>>>
>> >>>> <f:ajax execute="@this" render="#{cc.clientId}:image"/>
>> >>>>
>> >>>> But when I do that, I get this error...
>> >>>>
>> >>>> <f:ajax> contains an unknown id
>> >>>>
>> >>>> 'j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image'
>> >>>>
>> >>>> ...when I load the page, even though that is the correct client id
>> >>>> (as
>> >>>> evidenced from the request data above). Evidently, we're supposed to
>> >>>> use the
>> >>>> component id and not the client id?
>> >>>
>> >>> When specifying execute/render ids for <f:ajax>, the id resolution
>> >>> behavior is similar to findComponent(). So, if you specify a
>> >>> relative id, eg. "image", this should be resolved relative to the
>> >>> nearest naming container. In your case, that would be the
>> >>> composite component. In order to specify an absolute id, you would
>> >>> prefix the id with ":", eg. ":foo:mycompositecomp:image".
>> >>>
>> >>>
>> >>> Ah, okay, I missed that in the docs. Thanks for the explanation.
>> >>>
>> >>>
>> >>> david
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>> >
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>
>
>
> --
> Mit freundlichen Grüßen / Kind regards
> Alexander Bell
>
> J4Fry OpenSource Community
> Internet: http://www.j4fry.org
> E-Mail: Alexander.Bell@j4fry.org
> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [Fwd: Re: f:ajax not working inside composite components?]
Posted by Alexander Bell <Al...@j4fry.org>.
Hi Matthias,
I suppose Ganesh doesn't mean the bug of UIRepeat.
We've implemented the ajax in that way that you have to use the client id
(so the id of the HTML element) in "execute" and "render".
Andy Schwartz wrote there's an extra colon possibility which you can add to
an ID in "render" for an absolute ID.
Relative ID: image
Absolute ID: :myForm:myNamingContainer:image
HTML ID:
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
So for me it makes sense to use the JSF ID which should be resolved relative
to the nearest naming container --> we have to adjust our Ajax. In my
opinion we should not use the HTML ID because it's tricky to put the HTML ID
in "execute" or "render"
regards alex
2009/5/13 Matthias Wessendorf <ma...@apache.org>
> On Wed, May 13, 2009 at 8:12 PM, Matthias Wessendorf <ma...@apache.org>
> wrote:
> >>
> >> P.S.: For the curious ones: The reason why Davids code doesn't work
> because
> >> there is some bug in the decode processing of ui:repeat that Ryan is
> >> currently fixing ...
> >
> > I read that, but I guess they just fix it in their internal repo,
> > not in the REAL facelets that has the *right* license, right ?!
>
> ui:repeat has some issue:
>
> https://issues.apache.org/jira/browse/TRINIDAD-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707051#action_12707051
>
> (I know this is kinda offtopic)
>
> -M
>
>
> >
> >
> >
> >>
> >> -------- Original-Nachricht --------
> >> Betreff: Re: f:ajax not working inside composite components?
> >> Datum: Tue, 12 May 2009 14:39:58 -0700
> >> Von: Ryan Lubke <Ry...@SUN.COM>
> >> Antwort an: JSR 314 Open Mailing list <JS...@JCP.ORG>
> >> An: JSR-314-OPEN@JCP.ORG
> >> Referenzen: <
> 75fa9e650905120936p114faae7g987969d2e0b7ce1d@mail.gmail.com>
> >> <4A...@oracle.com>
> >> <75...@mail.gmail.com>
> >>
> >>
> >>
> >> On 5/12/09 2:17 PM, David Geary wrote:
> >>>
> >>> 2009/5/12 Andy Schwartz <andy.schwartz@oracle.com
> >>> <ma...@oracle.com>>
> >>>
> >>> Hi David -
> >>>
> >>>
> >>> Hi Andy,
> >>>
> >>> Thanks for responding.
> >>>
> >>> David Geary wrote On 5/12/2009 12:36 PM ET:
> >>>>
> >>>> <h:selectOneMenu id="menu"
> >>>> value="#{place.zoomIndex}"
> >>>> valueChangeListener="#{place.zoomChanged}"
> >>>> style="font-size:13px;font-family:Palatino">
> >>>>
> >>>> <f:selectItems value="#{places.zoomLevelItems}"/>
> >>>> *<f:ajax execute="@this" render="image"/>
> >>>> *
> >>>> </h:selectOneMenu>
> >>>
> >>> This looks good to me.
> >>>
> >>>
> >>> Yup. I thought that perhaps I was failing validation for some reason,
> so I
> >>> added immediate="true" to the f:ajax tag, but it didn't fix the
> problem. :(
> >>>
> >>>> With FireBug, I've verified that a POST request is indeed executed
> when I
> >>>> change the zoom level, and it appears that everything is in order:
> >>>>
> >>>> form form
> >>>>
> >>>>
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
> >>>> 3
> >>>> javax.faces.ViewState -1363564553004911965:-1863826268811277742
> >>>> javax.faces.behavior.event valueChange
> >>>> javax.faces.partial.ajax true
> >>>> javax.faces.partial.event change
> >>>> javax.faces.partial.execute
> >>>>
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
> >>>> javax.faces.partial.render
> >>>>
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
> >>>> javax.faces.source
> >>>>
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
> >>>
> >>> And the request payload looks right - seems like all of the
> >>> necessary information is present. (Though, man, those
> >>> auto-generated client ids sure are huge!)
> >>>
> >>>
> >>> Yes, it looks right to me too.
> >>>>
> >>>> I get a response back that looks like this:
> >>>>
> >>>> <?xml version="1.0" encoding="utf-8"?>
> >>>> <partial-response><changes><update
> >>>>
> id="javax.faces.ViewState"><![CDATA[1747337848471748955:2683565346534242854
> >>>> ]]></update></changes></partial-response>
> >>>>
> >>>> However, with f:ajax, my value change listener is never invoked on the
> >>>> server, so the menu doesn't update, even though I've specified that
> the menu
> >>>> should go through the execute phase of the lifecycle.
> >>>>
> >>>> Does anyone know why my value change listener is not invoked? Am I
> doing
> >>>> something wrong, or is this a bug?
> >>>
> >>> Seems like the execute portion of the lifecycle is not being
> >>> invoked properly. I don't see anything wrong in your code - so I
> >>> suspect there is a bug here.
> >>>
> >>>
> >>> I put a phase listener in the app to monitor the lifecycle, and all six
> >>> phases of the lifecycle are invoked, in the correct order when the ajax
> >>> request is made, but my value change listener is still not invoked.
> It's
> >>> interesting to note that when I remove the f:ajax tag, and add an
> >>> onchange="submit()" attribute to the menu, my value change listener
> does get
> >>> invoked, so it definitely seems like a bug to me. I can't think of any
> good
> >>> reason for the difference in behavior between the Ajax and non-Ajax
> >>> versions.
> >>>
> >>> It seems to me that the lifecycle is executing properly, but it's not
> >>> processing my menu, even though I've got execute="@this", and that
> >>> information is apparently correctly passed to the server.
> >>>
> >>> Is anyone from the RI team listening? Ryan? I can JAR up the app, and
> send
> >>> it to interested parties. I'd really like to get this fixed so I can
> nail
> >>> down this demo for JavaOne. It's a pretty cool demo, but it looses much
> of
> >>> its appeal when it doesn't work.
> >>
> >> Feel free to send it my way.
> >>>
> >>> Help!!
> >>>>
> >>>> btw, here are a couple of interesting datapoints:
> >>>>
> >>>> 1. I have breakpoints in jsf.ajax.request and jsf.ajax.response. The
> >>>> request breakpoint is hit, but the response is not. The return status
> for
> >>>> the response is 200, so there are apparently no errors.
> >>>>
> >>>> 2. I thought, from Jim Driscoll's blog about f:ajax, that we had to
> >>>> specify client ids for execute and render, so I originally had this:
> >>>>
> >>>> <f:ajax execute="@this" render="#{cc.clientId}:image"/>
> >>>>
> >>>> But when I do that, I get this error...
> >>>>
> >>>> <f:ajax> contains an unknown id
> >>>>
> 'j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image'
> >>>>
> >>>> ...when I load the page, even though that is the correct client id (as
> >>>> evidenced from the request data above). Evidently, we're supposed to
> use the
> >>>> component id and not the client id?
> >>>
> >>> When specifying execute/render ids for <f:ajax>, the id resolution
> >>> behavior is similar to findComponent(). So, if you specify a
> >>> relative id, eg. "image", this should be resolved relative to the
> >>> nearest naming container. In your case, that would be the
> >>> composite component. In order to specify an absolute id, you would
> >>> prefix the id with ":", eg. ":foo:mycompositecomp:image".
> >>>
> >>>
> >>> Ah, okay, I missed that in the docs. Thanks for the explanation.
> >>>
> >>>
> >>> david
> >>
> >>
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
--
Mit freundlichen Grüßen / Kind regards
Alexander Bell
J4Fry OpenSource Community
Internet: http://www.j4fry.org
E-Mail: Alexander.Bell@j4fry.org
Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: [Fwd: Re: f:ajax not working inside composite components?]
Posted by Matthias Wessendorf <ma...@apache.org>.
On Wed, May 13, 2009 at 8:12 PM, Matthias Wessendorf <ma...@apache.org> wrote:
>>
>> P.S.: For the curious ones: The reason why Davids code doesn't work because
>> there is some bug in the decode processing of ui:repeat that Ryan is
>> currently fixing ...
>
> I read that, but I guess they just fix it in their internal repo,
> not in the REAL facelets that has the *right* license, right ?!
ui:repeat has some issue:
https://issues.apache.org/jira/browse/TRINIDAD-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707051#action_12707051
(I know this is kinda offtopic)
-M
>
>
>
>>
>> -------- Original-Nachricht --------
>> Betreff: Re: f:ajax not working inside composite components?
>> Datum: Tue, 12 May 2009 14:39:58 -0700
>> Von: Ryan Lubke <Ry...@SUN.COM>
>> Antwort an: JSR 314 Open Mailing list <JS...@JCP.ORG>
>> An: JSR-314-OPEN@JCP.ORG
>> Referenzen: <75...@mail.gmail.com>
>> <4A...@oracle.com>
>> <75...@mail.gmail.com>
>>
>>
>>
>> On 5/12/09 2:17 PM, David Geary wrote:
>>>
>>> 2009/5/12 Andy Schwartz <andy.schwartz@oracle.com
>>> <ma...@oracle.com>>
>>>
>>> Hi David -
>>>
>>>
>>> Hi Andy,
>>>
>>> Thanks for responding.
>>>
>>> David Geary wrote On 5/12/2009 12:36 PM ET:
>>>>
>>>> <h:selectOneMenu id="menu"
>>>> value="#{place.zoomIndex}"
>>>> valueChangeListener="#{place.zoomChanged}"
>>>> style="font-size:13px;font-family:Palatino">
>>>>
>>>> <f:selectItems value="#{places.zoomLevelItems}"/>
>>>> *<f:ajax execute="@this" render="image"/>
>>>> *
>>>> </h:selectOneMenu>
>>>
>>> This looks good to me.
>>>
>>>
>>> Yup. I thought that perhaps I was failing validation for some reason, so I
>>> added immediate="true" to the f:ajax tag, but it didn't fix the problem. :(
>>>
>>>> With FireBug, I've verified that a POST request is indeed executed when I
>>>> change the zoom level, and it appears that everything is in order:
>>>>
>>>> form form
>>>>
>>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>> 3
>>>> javax.faces.ViewState -1363564553004911965:-1863826268811277742
>>>> javax.faces.behavior.event valueChange
>>>> javax.faces.partial.ajax true
>>>> javax.faces.partial.event change
>>>> javax.faces.partial.execute
>>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>> javax.faces.partial.render
>>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>>>> javax.faces.source
>>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>
>>> And the request payload looks right - seems like all of the
>>> necessary information is present. (Though, man, those
>>> auto-generated client ids sure are huge!)
>>>
>>>
>>> Yes, it looks right to me too.
>>>>
>>>> I get a response back that looks like this:
>>>>
>>>> <?xml version="1.0" encoding="utf-8"?>
>>>> <partial-response><changes><update
>>>> id="javax.faces.ViewState"><![CDATA[1747337848471748955:2683565346534242854
>>>> ]]></update></changes></partial-response>
>>>>
>>>> However, with f:ajax, my value change listener is never invoked on the
>>>> server, so the menu doesn't update, even though I've specified that the menu
>>>> should go through the execute phase of the lifecycle.
>>>>
>>>> Does anyone know why my value change listener is not invoked? Am I doing
>>>> something wrong, or is this a bug?
>>>
>>> Seems like the execute portion of the lifecycle is not being
>>> invoked properly. I don't see anything wrong in your code - so I
>>> suspect there is a bug here.
>>>
>>>
>>> I put a phase listener in the app to monitor the lifecycle, and all six
>>> phases of the lifecycle are invoked, in the correct order when the ajax
>>> request is made, but my value change listener is still not invoked. It's
>>> interesting to note that when I remove the f:ajax tag, and add an
>>> onchange="submit()" attribute to the menu, my value change listener does get
>>> invoked, so it definitely seems like a bug to me. I can't think of any good
>>> reason for the difference in behavior between the Ajax and non-Ajax
>>> versions.
>>>
>>> It seems to me that the lifecycle is executing properly, but it's not
>>> processing my menu, even though I've got execute="@this", and that
>>> information is apparently correctly passed to the server.
>>>
>>> Is anyone from the RI team listening? Ryan? I can JAR up the app, and send
>>> it to interested parties. I'd really like to get this fixed so I can nail
>>> down this demo for JavaOne. It's a pretty cool demo, but it looses much of
>>> its appeal when it doesn't work.
>>
>> Feel free to send it my way.
>>>
>>> Help!!
>>>>
>>>> btw, here are a couple of interesting datapoints:
>>>>
>>>> 1. I have breakpoints in jsf.ajax.request and jsf.ajax.response. The
>>>> request breakpoint is hit, but the response is not. The return status for
>>>> the response is 200, so there are apparently no errors.
>>>>
>>>> 2. I thought, from Jim Driscoll's blog about f:ajax, that we had to
>>>> specify client ids for execute and render, so I originally had this:
>>>>
>>>> <f:ajax execute="@this" render="#{cc.clientId}:image"/>
>>>>
>>>> But when I do that, I get this error...
>>>>
>>>> <f:ajax> contains an unknown id
>>>> 'j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image'
>>>>
>>>> ...when I load the page, even though that is the correct client id (as
>>>> evidenced from the request data above). Evidently, we're supposed to use the
>>>> component id and not the client id?
>>>
>>> When specifying execute/render ids for <f:ajax>, the id resolution
>>> behavior is similar to findComponent(). So, if you specify a
>>> relative id, eg. "image", this should be resolved relative to the
>>> nearest naming container. In your case, that would be the
>>> composite component. In order to specify an absolute id, you would
>>> prefix the id with ":", eg. ":foo:mycompositecomp:image".
>>>
>>>
>>> Ah, okay, I missed that in the docs. Thanks for the explanation.
>>>
>>>
>>> david
>>
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [Fwd: Re: f:ajax not working inside composite components?]
Posted by Matthias Wessendorf <ma...@apache.org>.
>
> P.S.: For the curious ones: The reason why Davids code doesn't work because
> there is some bug in the decode processing of ui:repeat that Ryan is
> currently fixing ...
I read that, but I guess they just fix it in their internal repo,
not in the REAL facelets that has the *right* license, right ?!
>
> -------- Original-Nachricht --------
> Betreff: Re: f:ajax not working inside composite components?
> Datum: Tue, 12 May 2009 14:39:58 -0700
> Von: Ryan Lubke <Ry...@SUN.COM>
> Antwort an: JSR 314 Open Mailing list <JS...@JCP.ORG>
> An: JSR-314-OPEN@JCP.ORG
> Referenzen: <75...@mail.gmail.com>
> <4A...@oracle.com>
> <75...@mail.gmail.com>
>
>
>
> On 5/12/09 2:17 PM, David Geary wrote:
>>
>> 2009/5/12 Andy Schwartz <andy.schwartz@oracle.com
>> <ma...@oracle.com>>
>>
>> Hi David -
>>
>>
>> Hi Andy,
>>
>> Thanks for responding.
>>
>> David Geary wrote On 5/12/2009 12:36 PM ET:
>>>
>>> <h:selectOneMenu id="menu"
>>> value="#{place.zoomIndex}"
>>> valueChangeListener="#{place.zoomChanged}"
>>> style="font-size:13px;font-family:Palatino">
>>>
>>> <f:selectItems value="#{places.zoomLevelItems}"/>
>>> *<f:ajax execute="@this" render="image"/>
>>> *
>>> </h:selectOneMenu>
>>
>> This looks good to me.
>>
>>
>> Yup. I thought that perhaps I was failing validation for some reason, so I
>> added immediate="true" to the f:ajax tag, but it didn't fix the problem. :(
>>
>>> With FireBug, I've verified that a POST request is indeed executed when I
>>> change the zoom level, and it appears that everything is in order:
>>>
>>> form form
>>>
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>> 3
>>> javax.faces.ViewState -1363564553004911965:-1863826268811277742
>>> javax.faces.behavior.event valueChange
>>> javax.faces.partial.ajax true
>>> javax.faces.partial.event change
>>> javax.faces.partial.execute
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>> javax.faces.partial.render
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>>> javax.faces.source
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>
>> And the request payload looks right - seems like all of the
>> necessary information is present. (Though, man, those
>> auto-generated client ids sure are huge!)
>>
>>
>> Yes, it looks right to me too.
>>>
>>> I get a response back that looks like this:
>>>
>>> <?xml version="1.0" encoding="utf-8"?>
>>> <partial-response><changes><update
>>> id="javax.faces.ViewState"><![CDATA[1747337848471748955:2683565346534242854
>>> ]]></update></changes></partial-response>
>>>
>>> However, with f:ajax, my value change listener is never invoked on the
>>> server, so the menu doesn't update, even though I've specified that the menu
>>> should go through the execute phase of the lifecycle.
>>>
>>> Does anyone know why my value change listener is not invoked? Am I doing
>>> something wrong, or is this a bug?
>>
>> Seems like the execute portion of the lifecycle is not being
>> invoked properly. I don't see anything wrong in your code - so I
>> suspect there is a bug here.
>>
>>
>> I put a phase listener in the app to monitor the lifecycle, and all six
>> phases of the lifecycle are invoked, in the correct order when the ajax
>> request is made, but my value change listener is still not invoked. It's
>> interesting to note that when I remove the f:ajax tag, and add an
>> onchange="submit()" attribute to the menu, my value change listener does get
>> invoked, so it definitely seems like a bug to me. I can't think of any good
>> reason for the difference in behavior between the Ajax and non-Ajax
>> versions.
>>
>> It seems to me that the lifecycle is executing properly, but it's not
>> processing my menu, even though I've got execute="@this", and that
>> information is apparently correctly passed to the server.
>>
>> Is anyone from the RI team listening? Ryan? I can JAR up the app, and send
>> it to interested parties. I'd really like to get this fixed so I can nail
>> down this demo for JavaOne. It's a pretty cool demo, but it looses much of
>> its appeal when it doesn't work.
>
> Feel free to send it my way.
>>
>> Help!!
>>>
>>> btw, here are a couple of interesting datapoints:
>>>
>>> 1. I have breakpoints in jsf.ajax.request and jsf.ajax.response. The
>>> request breakpoint is hit, but the response is not. The return status for
>>> the response is 200, so there are apparently no errors.
>>>
>>> 2. I thought, from Jim Driscoll's blog about f:ajax, that we had to
>>> specify client ids for execute and render, so I originally had this:
>>>
>>> <f:ajax execute="@this" render="#{cc.clientId}:image"/>
>>>
>>> But when I do that, I get this error...
>>>
>>> <f:ajax> contains an unknown id
>>> 'j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image'
>>>
>>> ...when I load the page, even though that is the correct client id (as
>>> evidenced from the request data above). Evidently, we're supposed to use the
>>> component id and not the client id?
>>
>> When specifying execute/render ids for <f:ajax>, the id resolution
>> behavior is similar to findComponent(). So, if you specify a
>> relative id, eg. "image", this should be resolved relative to the
>> nearest naming container. In your case, that would be the
>> composite component. In order to specify an absolute id, you would
>> prefix the id with ":", eg. ":foo:mycompositecomp:image".
>>
>>
>> Ah, okay, I missed that in the docs. Thanks for the explanation.
>>
>>
>> david
>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
jsf.ajax.request parameters vs. f:ajax parameters
Posted by Ganesh <ga...@j4fry.org>.
Hi,
The confusion was based on the mixup between javascript parameters and
tag attributes. It's easy: The tag takes component ids and the
javascript function takes clientids.
Here's what the spec says on this:
table 10-3, f:ajax's render attribute:
If a literal is specified, it must be a space delimited String of
component identifiers and/or one of the keywords outlined in Section
14.2.2 “Keywords”. If not specified, then @none is the default . If a
ValueExpression is specified, it must refer to a property that returns a
Collection of Strings. Each String in the Collection must not contain
spaces.
table 14-1, jsf.ajax.request's render parameter:
A space delimited list of client identifiers or one of the keywords
(Section 14.2.2 “Keywords”). These reference the components that will be
processed during the “render” phase of the request processing lifecycle.
Best regards,
Ganesh
Re: [Fwd: Re: f:ajax not working inside composite components?]
Posted by Martin Marinschek <mm...@apache.org>.
Hi Werner,
AFAIK, this hasn't made it into Mojarra.
regards,
Martin
On 5/16/09, Werner Punz <we...@gmail.com> wrote:
> Two additional things:
> first of all all has to be resolved by the f:ajax tag for the javascript
> call into absolute client ids, otherwise the server cannot identify the
> components affected!
>
> Secondly as far as I recall Trinidad, Trinidad had some kine of
> wildcarding via :: constructs I am not sure if this also made it into
> Mojarra, it could be worth to check it out.
>
> Werner
>
>
>
> Werner Punz schrieb:
>> Alexander Bell schrieb:
>>> Hi Werner,
>>>
>>> of course you have to send the absolute id.
>>> But in the json attributes "execute" and "render" we should use the
>>> JSF id's (so not the html id of the element).
>>>
>>> Alex
>>>
>> Ok Sorry I did not get it the first time,
>> The resolvement on javascript level looks ok to me but
>> there are two corner cases we have to tackle here and afair this is
>> pretty much also like trinidad does it.
>>
>>
>> > Both kinds of behaviour - resolving ids either relative to the
>> > nearest naming container or prepending them with a ":" to mark
>> > them absolute - cannot be found in the spec.
>>
>> That is also like Trinidad does it afaik, and it makes sense in a way
>> that you can trigger ppr updates outside of a given naming container
>> and can use short abbreviated ids inside, so I think we have to follow
>> the route. It does not make any difference on the javascript side
>> because both cases have to be resolved to absolute html ids which then
>> can be processed by the server!
>>
>> I would follow Mojarras route in this case like in so many not fully
>> specified.
>>
>> Werner
>>
>>
>>
>>
>>> 2009/5/15 Werner Punz <werner.punz@gmail.com
>>> <ma...@gmail.com>>
>>>
>>> From a logical standpoint you cannot avoid to send the entire
>>> abslute (html) id
>>> because otherwise on the server side you cannot
>>> identify the component properly.
>>> If you take the relative id, a proper identification within the
>>> component tree is impossible.
>>>
>>> So the id sent down has to be the absolute id otherwise we do not
>>> have a chance of identifying the affected components properly!
>>>
>>>
>>> Werner
>>>
>>>
>>>
>>> Ganesh schrieb:
>>>
>>> Hi everybody who is involved with MyFaces 2.0,
>>>
>>> have you seen this?
>>>
>>> From this:
>>>
>>> <h:selectOneMenu id="menu"
>>> value="#{place.zoomIndex}"
>>> valueChangeListener="#{place.zoomChanged}"
>>> style="font-size:13px;font-family:Palatino">
>>>
>>> <f:selectItems value="#{places.zoomLevelItems}"/>
>>> *<f:ajax execute="@this" render="image"/>
>>> *
>>> </h:selectOneMenu>
>>>
>>> ,nested inside a ui:repeat and a composition, Mojarra creates
>>> this AJAX request:
>>>
>>> form form
>>>
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>
>>>
>>> 3
>>> javax.faces.ViewState -1363564553004911965:-1863826268811277742
>>> javax.faces.behavior.event valueChange
>>> javax.faces.partial.ajax true
>>> javax.faces.partial.event change
>>> javax.faces.partial.execute
>>>
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>
>>>
>>>
>>> javax.faces.partial.render
>>>
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>>>
>>>
>>>
>>> javax.faces.source
>>>
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>
>>>
>>>
>>>
>>> In the JSR-314 spec it says in table 14-1:
>>>
>>> >>render - A space delimited list of client identifiers or one
>>> of the keywords (Section 14.2.2 “Keywords”). These reference the
>>> components that will be processed during the “render” phase of
>>> the request processing lifecycle.<<
>>>
>>> now, 'image' is definitely not a client identifier, but a
>>> component identifier. And there is more! Andy Schwarz comments
>>> on this:
>>>
>>> >>When specifying execute/render ids for <f:ajax>, the id
>>> resolution behavior is similar to findComponent(). So, if you
>>> specify a relative id, eg. "image", this should be resolved
>>> relative to the nearest naming container. In your case, that
>>> would be the composite component. In order to specify an
>>> absolute id, you would prefix the id with ":", eg.
>>> ":foo:mycompositecomp:image".<<
>>>
>>> Both kinds of behaviour - resolving ids either relative to the
>>> nearest naming container or prepending them with a ":" to mark
>>> them absolute - cannot be found in the spec.
>>>
>>> So, what do we do? Shall we follow Mojarras paths even if not
>>> covered by the specs words? Or do purposely break application
>>> portability to adhere to the specs?
>>>
>>> Please comment on this.
>>>
>>> Best regards,
>>> Ganesh
>>>
>>> P.S.: For the curious ones: The reason why Davids code doesn't
>>> work because there is some bug in the decode processing of
>>> ui:repeat that Ryan is currently fixing ...
>>>
>>> -------- Original-Nachricht --------
>>> Betreff: Re: f:ajax not working inside composite components?
>>> Datum: Tue, 12 May 2009 14:39:58 -0700
>>> Von: Ryan Lubke <Ryan.Lubke@SUN.COM
>>> <ma...@SUN.COM>>
>>> Antwort an: JSR 314 Open Mailing list <JSR-314-OPEN@JCP.ORG
>>> <ma...@JCP.ORG>>
>>> An: JSR-314-OPEN@JCP.ORG <ma...@JCP.ORG>
>>> Referenzen:
>>> <75fa9e650905120936p114faae7g987969d2e0b7ce1d@mail.gmail.com
>>>
>>> <ma...@mail.gmail.com>>
>>> <4A09ADCC.8040506@oracle.com
>>> <ma...@oracle.com>>
>>> <75fa9e650905121417h7e0b4758obbd3de65a428c03f@mail.gmail.com
>>>
>>> <ma...@mail.gmail.com>>
>>>
>>>
>>>
>>> On 5/12/09 2:17 PM, David Geary wrote:
>>>
>>> 2009/5/12 Andy Schwartz <andy.schwartz@oracle.com
>>> <ma...@oracle.com>
>>> <mailto:andy.schwartz@oracle.com
>>> <ma...@oracle.com>>>
>>>
>>> Hi David -
>>>
>>>
>>> Hi Andy,
>>>
>>> Thanks for responding.
>>>
>>> David Geary wrote On 5/12/2009 12:36 PM ET:
>>>
>>> <h:selectOneMenu id="menu"
>>> value="#{place.zoomIndex}"
>>> valueChangeListener="#{place.zoomChanged}"
>>> style="font-size:13px;font-family:Palatino">
>>>
>>> <f:selectItems value="#{places.zoomLevelItems}"/>
>>> *<f:ajax execute="@this" render="image"/>
>>> *
>>> </h:selectOneMenu>
>>>
>>>
>>> This looks good to me.
>>>
>>>
>>> Yup. I thought that perhaps I was failing validation for
>>> some reason, so I added immediate="true" to the f:ajax tag,
>>> but it didn't fix the problem. :(
>>>
>>> With FireBug, I've verified that a POST request is
>>> indeed executed when I change the zoom level, and it
>>> appears that everything is in order:
>>>
>>> form form
>>>
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>
>>>
>>> 3
>>> javax.faces.ViewState
>>> -1363564553004911965:-1863826268811277742
>>> javax.faces.behavior.event valueChange
>>> javax.faces.partial.ajax true
>>> javax.faces.partial.event change
>>> javax.faces.partial.execute
>>>
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>
>>>
>>>
>>> javax.faces.partial.render
>>>
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>>>
>>>
>>>
>>> javax.faces.source
>>>
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>
>>>
>>>
>>>
>>>
>>> And the request payload looks right - seems like all of
>>> the
>>> necessary information is present. (Though, man, those
>>> auto-generated client ids sure are huge!)
>>>
>>>
>>> Yes, it looks right to me too.
>>>
>>> I get a response back that looks like this:
>>>
>>> <?xml version="1.0" encoding="utf-8"?>
>>> <partial-response><changes><update
>>>
>>> id="javax.faces.ViewState"><![CDATA[1747337848471748955:2683565346534242854
>>>
>>>
>>>
>>> ]]></update></changes></partial-response>
>>>
>>> However, with f:ajax, my value change listener is never
>>> invoked on the server, so the menu doesn't update, even
>>> though I've specified that the menu should go through
>>> the execute phase of the lifecycle.
>>>
>>> Does anyone know why my value change listener is not
>>> invoked? Am I doing something wrong, or is this a bug?
>>>
>>>
>>> Seems like the execute portion of the lifecycle is not
>>> being
>>> invoked properly. I don't see anything wrong in your code
>>> - so I
>>> suspect there is a bug here.
>>>
>>>
>>> I put a phase listener in the app to monitor the lifecycle,
>>> and all six phases of the lifecycle are invoked, in the
>>> correct order when the ajax request is made, but my value
>>> change listener is still not invoked. It's interesting to
>>> note that when I remove the f:ajax tag, and add an
>>> onchange="submit()" attribute to the menu, my value change
>>> listener does get invoked, so it definitely seems like a bug
>>> to me. I can't think of any good reason for the difference
>>> in behavior between the Ajax and non-Ajax versions.
>>>
>>> It seems to me that the lifecycle is executing properly, but
>>> it's not processing my menu, even though I've got
>>> execute="@this", and that information is apparently
>>> correctly passed to the server.
>>>
>>> Is anyone from the RI team listening? Ryan? I can JAR up the
>>> app, and send it to interested parties. I'd really like to
>>> get this fixed so I can nail down this demo for JavaOne.
>>> It's a pretty cool demo, but it looses much of its appeal
>>> when it doesn't work.
>>>
>>> Feel free to send it my way.
>>>
>>>
>>> Help!!
>>>
>>>
>>> btw, here are a couple of interesting datapoints:
>>>
>>> 1. I have breakpoints in jsf.ajax.request and
>>> jsf.ajax.response. The request breakpoint is hit, but
>>> the response is not. The return status for the response
>>> is 200, so there are apparently no errors.
>>>
>>> 2. I thought, from Jim Driscoll's blog about f:ajax,
>>> that we had to specify client ids for execute and
>>> render, so I originally had this:
>>>
>>> <f:ajax execute="@this" render="#{cc.clientId}:image"/>
>>>
>>> But when I do that, I get this error...
>>>
>>> <f:ajax> contains an unknown id
>>>
>>> 'j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image'
>>>
>>>
>>>
>>>
>>> ...when I load the page, even though that is the correct
>>> client id (as evidenced from the request data above).
>>> Evidently, we're supposed to use the component id and
>>> not the client id?
>>>
>>>
>>> When specifying execute/render ids for <f:ajax>, the id
>>> resolution
>>> behavior is similar to findComponent(). So, if you
>>> specify a
>>> relative id, eg. "image", this should be resolved
>>> relative to the
>>> nearest naming container. In your case, that would be the
>>> composite component. In order to specify an absolute id,
>>> you would
>>> prefix the id with ":", eg. ":foo:mycompositecomp:image".
>>>
>>>
>>> Ah, okay, I missed that in the docs. Thanks for the
>>> explanation.
>>>
>>>
>>> david
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Mit freundlichen Grüßen / Kind regards
>>> Alexander Bell
>>>
>>> J4Fry OpenSource Community
>>> Internet: http://www.j4fry.org
>>> E-Mail: Alexander.Bell@j4fry.org <ma...@j4fry.org>
>>> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>>>
>>
>>
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [Fwd: Re: f:ajax not working inside composite components?]
Posted by Werner Punz <we...@gmail.com>.
Two additional things:
first of all all has to be resolved by the f:ajax tag for the javascript
call into absolute client ids, otherwise the server cannot identify the
components affected!
Secondly as far as I recall Trinidad, Trinidad had some kine of
wildcarding via :: constructs I am not sure if this also made it into
Mojarra, it could be worth to check it out.
Werner
Werner Punz schrieb:
> Alexander Bell schrieb:
>> Hi Werner,
>>
>> of course you have to send the absolute id.
>> But in the json attributes "execute" and "render" we should use the
>> JSF id's (so not the html id of the element).
>>
>> Alex
>>
> Ok Sorry I did not get it the first time,
> The resolvement on javascript level looks ok to me but
> there are two corner cases we have to tackle here and afair this is
> pretty much also like trinidad does it.
>
>
> > Both kinds of behaviour - resolving ids either relative to the
> > nearest naming container or prepending them with a ":" to mark
> > them absolute - cannot be found in the spec.
>
> That is also like Trinidad does it afaik, and it makes sense in a way
> that you can trigger ppr updates outside of a given naming container
> and can use short abbreviated ids inside, so I think we have to follow
> the route. It does not make any difference on the javascript side
> because both cases have to be resolved to absolute html ids which then
> can be processed by the server!
>
> I would follow Mojarras route in this case like in so many not fully
> specified.
>
> Werner
>
>
>
>
>> 2009/5/15 Werner Punz <werner.punz@gmail.com
>> <ma...@gmail.com>>
>>
>> From a logical standpoint you cannot avoid to send the entire
>> abslute (html) id
>> because otherwise on the server side you cannot
>> identify the component properly.
>> If you take the relative id, a proper identification within the
>> component tree is impossible.
>>
>> So the id sent down has to be the absolute id otherwise we do not
>> have a chance of identifying the affected components properly!
>>
>>
>> Werner
>>
>>
>>
>> Ganesh schrieb:
>>
>> Hi everybody who is involved with MyFaces 2.0,
>>
>> have you seen this?
>>
>> From this:
>>
>> <h:selectOneMenu id="menu"
>> value="#{place.zoomIndex}"
>> valueChangeListener="#{place.zoomChanged}"
>> style="font-size:13px;font-family:Palatino">
>>
>> <f:selectItems value="#{places.zoomLevelItems}"/>
>> *<f:ajax execute="@this" render="image"/>
>> *
>> </h:selectOneMenu>
>>
>> ,nested inside a ui:repeat and a composition, Mojarra creates
>> this AJAX request:
>>
>> form form
>>
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>
>> 3
>> javax.faces.ViewState -1363564553004911965:-1863826268811277742
>> javax.faces.behavior.event valueChange
>> javax.faces.partial.ajax true
>> javax.faces.partial.event change
>> javax.faces.partial.execute
>>
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>
>>
>> javax.faces.partial.render
>>
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>>
>>
>> javax.faces.source
>>
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>
>>
>>
>> In the JSR-314 spec it says in table 14-1:
>>
>> >>render - A space delimited list of client identifiers or one
>> of the keywords (Section 14.2.2 “Keywords”). These reference the
>> components that will be processed during the “render” phase of
>> the request processing lifecycle.<<
>>
>> now, 'image' is definitely not a client identifier, but a
>> component identifier. And there is more! Andy Schwarz comments
>> on this:
>>
>> >>When specifying execute/render ids for <f:ajax>, the id
>> resolution behavior is similar to findComponent(). So, if you
>> specify a relative id, eg. "image", this should be resolved
>> relative to the nearest naming container. In your case, that
>> would be the composite component. In order to specify an
>> absolute id, you would prefix the id with ":", eg.
>> ":foo:mycompositecomp:image".<<
>>
>> Both kinds of behaviour - resolving ids either relative to the
>> nearest naming container or prepending them with a ":" to mark
>> them absolute - cannot be found in the spec.
>>
>> So, what do we do? Shall we follow Mojarras paths even if not
>> covered by the specs words? Or do purposely break application
>> portability to adhere to the specs?
>>
>> Please comment on this.
>>
>> Best regards,
>> Ganesh
>>
>> P.S.: For the curious ones: The reason why Davids code doesn't
>> work because there is some bug in the decode processing of
>> ui:repeat that Ryan is currently fixing ...
>>
>> -------- Original-Nachricht --------
>> Betreff: Re: f:ajax not working inside composite components?
>> Datum: Tue, 12 May 2009 14:39:58 -0700
>> Von: Ryan Lubke <Ryan.Lubke@SUN.COM
>> <ma...@SUN.COM>>
>> Antwort an: JSR 314 Open Mailing list <JSR-314-OPEN@JCP.ORG
>> <ma...@JCP.ORG>>
>> An: JSR-314-OPEN@JCP.ORG <ma...@JCP.ORG>
>> Referenzen:
>> <75fa9e650905120936p114faae7g987969d2e0b7ce1d@mail.gmail.com
>>
>> <ma...@mail.gmail.com>>
>> <4A09ADCC.8040506@oracle.com
>> <ma...@oracle.com>>
>> <75fa9e650905121417h7e0b4758obbd3de65a428c03f@mail.gmail.com
>>
>> <ma...@mail.gmail.com>>
>>
>>
>>
>> On 5/12/09 2:17 PM, David Geary wrote:
>>
>> 2009/5/12 Andy Schwartz <andy.schwartz@oracle.com
>> <ma...@oracle.com>
>> <mailto:andy.schwartz@oracle.com
>> <ma...@oracle.com>>>
>>
>> Hi David -
>>
>>
>> Hi Andy,
>>
>> Thanks for responding.
>>
>> David Geary wrote On 5/12/2009 12:36 PM ET:
>>
>> <h:selectOneMenu id="menu"
>> value="#{place.zoomIndex}"
>> valueChangeListener="#{place.zoomChanged}"
>> style="font-size:13px;font-family:Palatino">
>>
>> <f:selectItems value="#{places.zoomLevelItems}"/>
>> *<f:ajax execute="@this" render="image"/>
>> *
>> </h:selectOneMenu>
>>
>>
>> This looks good to me.
>>
>>
>> Yup. I thought that perhaps I was failing validation for
>> some reason, so I added immediate="true" to the f:ajax tag,
>> but it didn't fix the problem. :(
>>
>> With FireBug, I've verified that a POST request is
>> indeed executed when I change the zoom level, and it
>> appears that everything is in order:
>>
>> form form
>>
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>
>> 3
>> javax.faces.ViewState
>> -1363564553004911965:-1863826268811277742
>> javax.faces.behavior.event valueChange
>> javax.faces.partial.ajax true
>> javax.faces.partial.event change
>> javax.faces.partial.execute
>>
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>
>>
>> javax.faces.partial.render
>>
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>>
>>
>> javax.faces.source
>>
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>
>>
>>
>>
>> And the request payload looks right - seems like all of
>> the
>> necessary information is present. (Though, man, those
>> auto-generated client ids sure are huge!)
>>
>>
>> Yes, it looks right to me too.
>>
>> I get a response back that looks like this:
>>
>> <?xml version="1.0" encoding="utf-8"?>
>> <partial-response><changes><update
>>
>> id="javax.faces.ViewState"><![CDATA[1747337848471748955:2683565346534242854
>>
>>
>> ]]></update></changes></partial-response>
>>
>> However, with f:ajax, my value change listener is never
>> invoked on the server, so the menu doesn't update, even
>> though I've specified that the menu should go through
>> the execute phase of the lifecycle.
>>
>> Does anyone know why my value change listener is not
>> invoked? Am I doing something wrong, or is this a bug?
>>
>>
>> Seems like the execute portion of the lifecycle is not
>> being
>> invoked properly. I don't see anything wrong in your code
>> - so I
>> suspect there is a bug here.
>>
>>
>> I put a phase listener in the app to monitor the lifecycle,
>> and all six phases of the lifecycle are invoked, in the
>> correct order when the ajax request is made, but my value
>> change listener is still not invoked. It's interesting to
>> note that when I remove the f:ajax tag, and add an
>> onchange="submit()" attribute to the menu, my value change
>> listener does get invoked, so it definitely seems like a bug
>> to me. I can't think of any good reason for the difference
>> in behavior between the Ajax and non-Ajax versions.
>>
>> It seems to me that the lifecycle is executing properly, but
>> it's not processing my menu, even though I've got
>> execute="@this", and that information is apparently
>> correctly passed to the server.
>>
>> Is anyone from the RI team listening? Ryan? I can JAR up the
>> app, and send it to interested parties. I'd really like to
>> get this fixed so I can nail down this demo for JavaOne.
>> It's a pretty cool demo, but it looses much of its appeal
>> when it doesn't work.
>>
>> Feel free to send it my way.
>>
>>
>> Help!!
>>
>>
>> btw, here are a couple of interesting datapoints:
>>
>> 1. I have breakpoints in jsf.ajax.request and
>> jsf.ajax.response. The request breakpoint is hit, but
>> the response is not. The return status for the response
>> is 200, so there are apparently no errors.
>>
>> 2. I thought, from Jim Driscoll's blog about f:ajax,
>> that we had to specify client ids for execute and
>> render, so I originally had this:
>>
>> <f:ajax execute="@this" render="#{cc.clientId}:image"/>
>>
>> But when I do that, I get this error...
>>
>> <f:ajax> contains an unknown id
>>
>> 'j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image'
>>
>>
>>
>> ...when I load the page, even though that is the correct
>> client id (as evidenced from the request data above).
>> Evidently, we're supposed to use the component id and
>> not the client id?
>>
>>
>> When specifying execute/render ids for <f:ajax>, the id
>> resolution
>> behavior is similar to findComponent(). So, if you
>> specify a
>> relative id, eg. "image", this should be resolved
>> relative to the
>> nearest naming container. In your case, that would be the
>> composite component. In order to specify an absolute id,
>> you would
>> prefix the id with ":", eg. ":foo:mycompositecomp:image".
>>
>>
>> Ah, okay, I missed that in the docs. Thanks for the
>> explanation.
>>
>>
>> david
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Mit freundlichen Grüßen / Kind regards
>> Alexander Bell
>>
>> J4Fry OpenSource Community
>> Internet: http://www.j4fry.org
>> E-Mail: Alexander.Bell@j4fry.org <ma...@j4fry.org>
>> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>>
>
>
Re: [Fwd: Re: f:ajax not working inside composite components?]
Posted by Werner Punz <we...@gmail.com>.
Alexander Bell schrieb:
> Hi Werner,
>
> of course you have to send the absolute id.
> But in the json attributes "execute" and "render" we should use the JSF
> id's (so not the html id of the element).
>
> Alex
>
Ok Sorry I did not get it the first time,
The resolvement on javascript level looks ok to me but
there are two corner cases we have to tackle here and afair this is
pretty much also like trinidad does it.
> Both kinds of behaviour - resolving ids either relative to the
> nearest naming container or prepending them with a ":" to mark
> them absolute - cannot be found in the spec.
That is also like Trinidad does it afaik, and it makes sense in a way
that you can trigger ppr updates outside of a given naming container
and can use short abbreviated ids inside, so I think we have to follow
the route. It does not make any difference on the javascript side
because both cases have to be resolved to absolute html ids which then
can be processed by the server!
I would follow Mojarras route in this case like in so many not fully
specified.
Werner
> 2009/5/15 Werner Punz <werner.punz@gmail.com <ma...@gmail.com>>
>
> From a logical standpoint you cannot avoid to send the entire
> abslute (html) id
> because otherwise on the server side you cannot
> identify the component properly.
> If you take the relative id, a proper identification within the
> component tree is impossible.
>
> So the id sent down has to be the absolute id otherwise we do not
> have a chance of identifying the affected components properly!
>
>
> Werner
>
>
>
> Ganesh schrieb:
>
> Hi everybody who is involved with MyFaces 2.0,
>
> have you seen this?
>
> From this:
>
> <h:selectOneMenu id="menu"
> value="#{place.zoomIndex}"
> valueChangeListener="#{place.zoomChanged}"
> style="font-size:13px;font-family:Palatino">
>
> <f:selectItems value="#{places.zoomLevelItems}"/>
> *<f:ajax execute="@this" render="image"/>
> *
> </h:selectOneMenu>
>
> ,nested inside a ui:repeat and a composition, Mojarra creates
> this AJAX request:
>
> form form
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
> 3
> javax.faces.ViewState -1363564553004911965:-1863826268811277742
> javax.faces.behavior.event valueChange
> javax.faces.partial.ajax true
> javax.faces.partial.event change
> javax.faces.partial.execute
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>
> javax.faces.partial.render
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>
> javax.faces.source
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>
>
> In the JSR-314 spec it says in table 14-1:
>
> >>render - A space delimited list of client identifiers or one
> of the keywords (Section 14.2.2 “Keywords”). These reference the
> components that will be processed during the “render” phase of
> the request processing lifecycle.<<
>
> now, 'image' is definitely not a client identifier, but a
> component identifier. And there is more! Andy Schwarz comments
> on this:
>
> >>When specifying execute/render ids for <f:ajax>, the id
> resolution behavior is similar to findComponent(). So, if you
> specify a relative id, eg. "image", this should be resolved
> relative to the nearest naming container. In your case, that
> would be the composite component. In order to specify an
> absolute id, you would prefix the id with ":", eg.
> ":foo:mycompositecomp:image".<<
>
> Both kinds of behaviour - resolving ids either relative to the
> nearest naming container or prepending them with a ":" to mark
> them absolute - cannot be found in the spec.
>
> So, what do we do? Shall we follow Mojarras paths even if not
> covered by the specs words? Or do purposely break application
> portability to adhere to the specs?
>
> Please comment on this.
>
> Best regards,
> Ganesh
>
> P.S.: For the curious ones: The reason why Davids code doesn't
> work because there is some bug in the decode processing of
> ui:repeat that Ryan is currently fixing ...
>
> -------- Original-Nachricht --------
> Betreff: Re: f:ajax not working inside composite components?
> Datum: Tue, 12 May 2009 14:39:58 -0700
> Von: Ryan Lubke <Ryan.Lubke@SUN.COM <ma...@SUN.COM>>
> Antwort an: JSR 314 Open Mailing list <JSR-314-OPEN@JCP.ORG
> <ma...@JCP.ORG>>
> An: JSR-314-OPEN@JCP.ORG <ma...@JCP.ORG>
> Referenzen:
> <75fa9e650905120936p114faae7g987969d2e0b7ce1d@mail.gmail.com
> <ma...@mail.gmail.com>>
> <4A09ADCC.8040506@oracle.com
> <ma...@oracle.com>>
> <75fa9e650905121417h7e0b4758obbd3de65a428c03f@mail.gmail.com
> <ma...@mail.gmail.com>>
>
>
>
> On 5/12/09 2:17 PM, David Geary wrote:
>
> 2009/5/12 Andy Schwartz <andy.schwartz@oracle.com
> <ma...@oracle.com>
> <mailto:andy.schwartz@oracle.com
> <ma...@oracle.com>>>
>
> Hi David -
>
>
> Hi Andy,
>
> Thanks for responding.
>
> David Geary wrote On 5/12/2009 12:36 PM ET:
>
> <h:selectOneMenu id="menu"
> value="#{place.zoomIndex}"
> valueChangeListener="#{place.zoomChanged}"
> style="font-size:13px;font-family:Palatino">
>
> <f:selectItems value="#{places.zoomLevelItems}"/>
> *<f:ajax execute="@this" render="image"/>
> *
> </h:selectOneMenu>
>
>
> This looks good to me.
>
>
> Yup. I thought that perhaps I was failing validation for
> some reason, so I added immediate="true" to the f:ajax tag,
> but it didn't fix the problem. :(
>
> With FireBug, I've verified that a POST request is
> indeed executed when I change the zoom level, and it
> appears that everything is in order:
>
> form form
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
> 3
> javax.faces.ViewState
> -1363564553004911965:-1863826268811277742
> javax.faces.behavior.event valueChange
> javax.faces.partial.ajax true
> javax.faces.partial.event change
> javax.faces.partial.execute
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>
> javax.faces.partial.render
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>
> javax.faces.source
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>
>
>
> And the request payload looks right - seems like all of the
> necessary information is present. (Though, man, those
> auto-generated client ids sure are huge!)
>
>
> Yes, it looks right to me too.
>
> I get a response back that looks like this:
>
> <?xml version="1.0" encoding="utf-8"?>
> <partial-response><changes><update
> id="javax.faces.ViewState"><![CDATA[1747337848471748955:2683565346534242854
>
> ]]></update></changes></partial-response>
>
> However, with f:ajax, my value change listener is never
> invoked on the server, so the menu doesn't update, even
> though I've specified that the menu should go through
> the execute phase of the lifecycle.
>
> Does anyone know why my value change listener is not
> invoked? Am I doing something wrong, or is this a bug?
>
>
> Seems like the execute portion of the lifecycle is not being
> invoked properly. I don't see anything wrong in your code
> - so I
> suspect there is a bug here.
>
>
> I put a phase listener in the app to monitor the lifecycle,
> and all six phases of the lifecycle are invoked, in the
> correct order when the ajax request is made, but my value
> change listener is still not invoked. It's interesting to
> note that when I remove the f:ajax tag, and add an
> onchange="submit()" attribute to the menu, my value change
> listener does get invoked, so it definitely seems like a bug
> to me. I can't think of any good reason for the difference
> in behavior between the Ajax and non-Ajax versions.
>
> It seems to me that the lifecycle is executing properly, but
> it's not processing my menu, even though I've got
> execute="@this", and that information is apparently
> correctly passed to the server.
>
> Is anyone from the RI team listening? Ryan? I can JAR up the
> app, and send it to interested parties. I'd really like to
> get this fixed so I can nail down this demo for JavaOne.
> It's a pretty cool demo, but it looses much of its appeal
> when it doesn't work.
>
> Feel free to send it my way.
>
>
> Help!!
>
>
> btw, here are a couple of interesting datapoints:
>
> 1. I have breakpoints in jsf.ajax.request and
> jsf.ajax.response. The request breakpoint is hit, but
> the response is not. The return status for the response
> is 200, so there are apparently no errors.
>
> 2. I thought, from Jim Driscoll's blog about f:ajax,
> that we had to specify client ids for execute and
> render, so I originally had this:
>
> <f:ajax execute="@this" render="#{cc.clientId}:image"/>
>
> But when I do that, I get this error...
>
> <f:ajax> contains an unknown id
> 'j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image'
>
>
> ...when I load the page, even though that is the correct
> client id (as evidenced from the request data above).
> Evidently, we're supposed to use the component id and
> not the client id?
>
>
> When specifying execute/render ids for <f:ajax>, the id
> resolution
> behavior is similar to findComponent(). So, if you specify a
> relative id, eg. "image", this should be resolved
> relative to the
> nearest naming container. In your case, that would be the
> composite component. In order to specify an absolute id,
> you would
> prefix the id with ":", eg. ":foo:mycompositecomp:image".
>
>
> Ah, okay, I missed that in the docs. Thanks for the explanation.
>
>
> david
>
>
>
>
>
>
>
>
> --
> Mit freundlichen Grüßen / Kind regards
> Alexander Bell
>
> J4Fry OpenSource Community
> Internet: http://www.j4fry.org
> E-Mail: Alexander.Bell@j4fry.org <ma...@j4fry.org>
> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>
Re: [Fwd: Re: f:ajax not working inside composite components?]
Posted by Alexander Bell <Al...@j4fry.org>.
Hi Werner,
of course you have to send the absolute id.
But in the json attributes "execute" and "render" we should use the JSF id's
(so not the html id of the element).
Alex
2009/5/15 Werner Punz <we...@gmail.com>
> From a logical standpoint you cannot avoid to send the entire abslute
> (html) id
> because otherwise on the server side you cannot
> identify the component properly.
> If you take the relative id, a proper identification within the component
> tree is impossible.
>
> So the id sent down has to be the absolute id otherwise we do not have a
> chance of identifying the affected components properly!
>
>
> Werner
>
>
>
> Ganesh schrieb:
>
> Hi everybody who is involved with MyFaces 2.0,
>>
>> have you seen this?
>>
>> From this:
>>
>> <h:selectOneMenu id="menu"
>>> value="#{place.zoomIndex}"
>>> valueChangeListener="#{place.zoomChanged}"
>>> style="font-size:13px;font-family:Palatino">
>>>
>>> <f:selectItems value="#{places.zoomLevelItems}"/>
>>> *<f:ajax execute="@this" render="image"/>
>>> *
>>> </h:selectOneMenu>
>>>
>> ,nested inside a ui:repeat and a composition, Mojarra creates this AJAX
>> request:
>>
>> form form
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>> 3
>> javax.faces.ViewState -1363564553004911965:-1863826268811277742
>> javax.faces.behavior.event valueChange
>> javax.faces.partial.ajax true
>> javax.faces.partial.event change
>> javax.faces.partial.execute
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>
>> javax.faces.partial.render
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>>
>> javax.faces.source
>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>
>>
>> In the JSR-314 spec it says in table 14-1:
>>
>> >>render - A space delimited list of client identifiers or one of the
>> keywords (Section 14.2.2 “Keywords”). These reference the components that
>> will be processed during the “render” phase of the request processing
>> lifecycle.<<
>>
>> now, 'image' is definitely not a client identifier, but a component
>> identifier. And there is more! Andy Schwarz comments on this:
>>
>> >>When specifying execute/render ids for <f:ajax>, the id resolution
>> behavior is similar to findComponent(). So, if you specify a relative id,
>> eg. "image", this should be resolved relative to the nearest naming
>> container. In your case, that would be the composite component. In order to
>> specify an absolute id, you would prefix the id with ":", eg.
>> ":foo:mycompositecomp:image".<<
>>
>> Both kinds of behaviour - resolving ids either relative to the nearest
>> naming container or prepending them with a ":" to mark them absolute -
>> cannot be found in the spec.
>>
>> So, what do we do? Shall we follow Mojarras paths even if not covered by
>> the specs words? Or do purposely break application portability to adhere to
>> the specs?
>>
>> Please comment on this.
>>
>> Best regards,
>> Ganesh
>>
>> P.S.: For the curious ones: The reason why Davids code doesn't work
>> because there is some bug in the decode processing of ui:repeat that Ryan is
>> currently fixing ...
>>
>> -------- Original-Nachricht --------
>> Betreff: Re: f:ajax not working inside composite components?
>> Datum: Tue, 12 May 2009 14:39:58 -0700
>> Von: Ryan Lubke <Ry...@SUN.COM>
>> Antwort an: JSR 314 Open Mailing list <JS...@JCP.ORG>
>> An: JSR-314-OPEN@JCP.ORG
>> Referenzen: <75...@mail.gmail.com>
>> <4A...@oracle.com> <
>> 75fa9e650905121417h7e0b4758obbd3de65a428c03f@mail.gmail.com>
>>
>>
>>
>> On 5/12/09 2:17 PM, David Geary wrote:
>>
>>> 2009/5/12 Andy Schwartz <andy.schwartz@oracle.com <mailto:
>>> andy.schwartz@oracle.com>>
>>>
>>> Hi David -
>>>
>>>
>>> Hi Andy,
>>>
>>> Thanks for responding.
>>>
>>> David Geary wrote On 5/12/2009 12:36 PM ET:
>>>
>>>> <h:selectOneMenu id="menu"
>>>> value="#{place.zoomIndex}"
>>>> valueChangeListener="#{place.zoomChanged}"
>>>> style="font-size:13px;font-family:Palatino">
>>>>
>>>> <f:selectItems value="#{places.zoomLevelItems}"/>
>>>> *<f:ajax execute="@this" render="image"/>
>>>> *
>>>> </h:selectOneMenu>
>>>>
>>>
>>> This looks good to me.
>>>
>>>
>>> Yup. I thought that perhaps I was failing validation for some reason, so
>>> I added immediate="true" to the f:ajax tag, but it didn't fix the problem.
>>> :(
>>>
>>> With FireBug, I've verified that a POST request is indeed executed when
>>>> I change the zoom level, and it appears that everything is in order:
>>>>
>>>> form form
>>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>> 3
>>>> javax.faces.ViewState -1363564553004911965:-1863826268811277742
>>>> javax.faces.behavior.event valueChange
>>>> javax.faces.partial.ajax true
>>>> javax.faces.partial.event change
>>>> javax.faces.partial.execute
>>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>>
>>>> javax.faces.partial.render
>>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>>>>
>>>> javax.faces.source
>>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>>
>>>>
>>>
>>> And the request payload looks right - seems like all of the
>>> necessary information is present. (Though, man, those
>>> auto-generated client ids sure are huge!)
>>>
>>>
>>> Yes, it looks right to me too.
>>>
>>>> I get a response back that looks like this:
>>>>
>>>> <?xml version="1.0" encoding="utf-8"?>
>>>> <partial-response><changes><update
>>>> id="javax.faces.ViewState"><![CDATA[1747337848471748955:2683565346534242854
>>>> ]]></update></changes></partial-response>
>>>>
>>>> However, with f:ajax, my value change listener is never invoked on the
>>>> server, so the menu doesn't update, even though I've specified that the menu
>>>> should go through the execute phase of the lifecycle.
>>>>
>>>> Does anyone know why my value change listener is not invoked? Am I doing
>>>> something wrong, or is this a bug?
>>>>
>>>
>>> Seems like the execute portion of the lifecycle is not being
>>> invoked properly. I don't see anything wrong in your code - so I
>>> suspect there is a bug here.
>>>
>>>
>>> I put a phase listener in the app to monitor the lifecycle, and all six
>>> phases of the lifecycle are invoked, in the correct order when the ajax
>>> request is made, but my value change listener is still not invoked. It's
>>> interesting to note that when I remove the f:ajax tag, and add an
>>> onchange="submit()" attribute to the menu, my value change listener does get
>>> invoked, so it definitely seems like a bug to me. I can't think of any good
>>> reason for the difference in behavior between the Ajax and non-Ajax
>>> versions.
>>>
>>> It seems to me that the lifecycle is executing properly, but it's not
>>> processing my menu, even though I've got execute="@this", and that
>>> information is apparently correctly passed to the server.
>>>
>>> Is anyone from the RI team listening? Ryan? I can JAR up the app, and
>>> send it to interested parties. I'd really like to get this fixed so I can
>>> nail down this demo for JavaOne. It's a pretty cool demo, but it looses much
>>> of its appeal when it doesn't work.
>>>
>> Feel free to send it my way.
>>
>>>
>>> Help!!
>>>
>>>>
>>>> btw, here are a couple of interesting datapoints:
>>>>
>>>> 1. I have breakpoints in jsf.ajax.request and jsf.ajax.response. The
>>>> request breakpoint is hit, but the response is not. The return status for
>>>> the response is 200, so there are apparently no errors.
>>>>
>>>> 2. I thought, from Jim Driscoll's blog about f:ajax, that we had to
>>>> specify client ids for execute and render, so I originally had this:
>>>>
>>>> <f:ajax execute="@this" render="#{cc.clientId}:image"/>
>>>>
>>>> But when I do that, I get this error...
>>>>
>>>> <f:ajax> contains an unknown id
>>>> 'j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image'
>>>>
>>>>
>>>> ...when I load the page, even though that is the correct client id (as
>>>> evidenced from the request data above). Evidently, we're supposed to use the
>>>> component id and not the client id?
>>>>
>>>
>>> When specifying execute/render ids for <f:ajax>, the id resolution
>>> behavior is similar to findComponent(). So, if you specify a
>>> relative id, eg. "image", this should be resolved relative to the
>>> nearest naming container. In your case, that would be the
>>> composite component. In order to specify an absolute id, you would
>>> prefix the id with ":", eg. ":foo:mycompositecomp:image".
>>>
>>>
>>> Ah, okay, I missed that in the docs. Thanks for the explanation.
>>>
>>>
>>> david
>>>
>>
>>
>>
>>
>
--
Mit freundlichen Grüßen / Kind regards
Alexander Bell
J4Fry OpenSource Community
Internet: http://www.j4fry.org
E-Mail: Alexander.Bell@j4fry.org
Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: [Fwd: Re: f:ajax not working inside composite components?]
Posted by Werner Punz <we...@gmail.com>.
From a logical standpoint you cannot avoid to send the entire abslute
(html) id
because otherwise on the server side you cannot
identify the component properly.
If you take the relative id, a proper identification within the
component tree is impossible.
So the id sent down has to be the absolute id otherwise we do not have a
chance of identifying the affected components properly!
Werner
Ganesh schrieb:
> Hi everybody who is involved with MyFaces 2.0,
>
> have you seen this?
>
> From this:
>
>> <h:selectOneMenu id="menu"
>> value="#{place.zoomIndex}"
>> valueChangeListener="#{place.zoomChanged}"
>> style="font-size:13px;font-family:Palatino">
>>
>> <f:selectItems value="#{places.zoomLevelItems}"/>
>> *<f:ajax execute="@this" render="image"/>
>> *
>> </h:selectOneMenu>
> ,nested inside a ui:repeat and a composition, Mojarra creates this AJAX
> request:
>
> form form
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
> 3
> javax.faces.ViewState -1363564553004911965:-1863826268811277742
> javax.faces.behavior.event valueChange
> javax.faces.partial.ajax true
> javax.faces.partial.event change
> javax.faces.partial.execute
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>
> javax.faces.partial.render
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>
> javax.faces.source
> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>
>
> In the JSR-314 spec it says in table 14-1:
>
> >>render - A space delimited list of client identifiers or one of the
> keywords (Section 14.2.2 “Keywords”). These reference the components
> that will be processed during the “render” phase of the request
> processing lifecycle.<<
>
> now, 'image' is definitely not a client identifier, but a component
> identifier. And there is more! Andy Schwarz comments on this:
>
> >>When specifying execute/render ids for <f:ajax>, the id resolution
> behavior is similar to findComponent(). So, if you specify a relative
> id, eg. "image", this should be resolved relative to the nearest naming
> container. In your case, that would be the composite component. In order
> to specify an absolute id, you would prefix the id with ":", eg.
> ":foo:mycompositecomp:image".<<
>
> Both kinds of behaviour - resolving ids either relative to the nearest
> naming container or prepending them with a ":" to mark them absolute -
> cannot be found in the spec.
>
> So, what do we do? Shall we follow Mojarras paths even if not covered by
> the specs words? Or do purposely break application portability to adhere
> to the specs?
>
> Please comment on this.
>
> Best regards,
> Ganesh
>
> P.S.: For the curious ones: The reason why Davids code doesn't work
> because there is some bug in the decode processing of ui:repeat that
> Ryan is currently fixing ...
>
> -------- Original-Nachricht --------
> Betreff: Re: f:ajax not working inside composite components?
> Datum: Tue, 12 May 2009 14:39:58 -0700
> Von: Ryan Lubke <Ry...@SUN.COM>
> Antwort an: JSR 314 Open Mailing list <JS...@JCP.ORG>
> An: JSR-314-OPEN@JCP.ORG
> Referenzen:
> <75...@mail.gmail.com>
> <4A...@oracle.com>
> <75...@mail.gmail.com>
>
>
>
> On 5/12/09 2:17 PM, David Geary wrote:
>> 2009/5/12 Andy Schwartz <andy.schwartz@oracle.com
>> <ma...@oracle.com>>
>>
>> Hi David -
>>
>>
>> Hi Andy,
>>
>> Thanks for responding.
>>
>> David Geary wrote On 5/12/2009 12:36 PM ET:
>>> <h:selectOneMenu id="menu"
>>> value="#{place.zoomIndex}"
>>> valueChangeListener="#{place.zoomChanged}"
>>> style="font-size:13px;font-family:Palatino">
>>>
>>> <f:selectItems value="#{places.zoomLevelItems}"/>
>>> *<f:ajax execute="@this" render="image"/>
>>> *
>>> </h:selectOneMenu>
>>
>> This looks good to me.
>>
>>
>> Yup. I thought that perhaps I was failing validation for some reason,
>> so I added immediate="true" to the f:ajax tag, but it didn't fix the
>> problem. :(
>>
>>> With FireBug, I've verified that a POST request is indeed executed
>>> when I change the zoom level, and it appears that everything is in
>>> order:
>>>
>>> form form
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>> 3
>>> javax.faces.ViewState -1363564553004911965:-1863826268811277742
>>> javax.faces.behavior.event valueChange
>>> javax.faces.partial.ajax true
>>> javax.faces.partial.event change
>>> javax.faces.partial.execute
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>
>>> javax.faces.partial.render
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
>>>
>>> javax.faces.source
>>> j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
>>>
>>
>> And the request payload looks right - seems like all of the
>> necessary information is present. (Though, man, those
>> auto-generated client ids sure are huge!)
>>
>>
>> Yes, it looks right to me too.
>>> I get a response back that looks like this:
>>>
>>> <?xml version="1.0" encoding="utf-8"?>
>>> <partial-response><changes><update
>>> id="javax.faces.ViewState"><![CDATA[1747337848471748955:2683565346534242854
>>>
>>> ]]></update></changes></partial-response>
>>>
>>> However, with f:ajax, my value change listener is never invoked on
>>> the server, so the menu doesn't update, even though I've specified
>>> that the menu should go through the execute phase of the lifecycle.
>>>
>>> Does anyone know why my value change listener is not invoked? Am I
>>> doing something wrong, or is this a bug?
>>
>> Seems like the execute portion of the lifecycle is not being
>> invoked properly. I don't see anything wrong in your code - so I
>> suspect there is a bug here.
>>
>>
>> I put a phase listener in the app to monitor the lifecycle, and all
>> six phases of the lifecycle are invoked, in the correct order when the
>> ajax request is made, but my value change listener is still not
>> invoked. It's interesting to note that when I remove the f:ajax tag,
>> and add an onchange="submit()" attribute to the menu, my value change
>> listener does get invoked, so it definitely seems like a bug to me. I
>> can't think of any good reason for the difference in behavior between
>> the Ajax and non-Ajax versions.
>>
>> It seems to me that the lifecycle is executing properly, but it's not
>> processing my menu, even though I've got execute="@this", and that
>> information is apparently correctly passed to the server.
>>
>> Is anyone from the RI team listening? Ryan? I can JAR up the app, and
>> send it to interested parties. I'd really like to get this fixed so I
>> can nail down this demo for JavaOne. It's a pretty cool demo, but it
>> looses much of its appeal when it doesn't work.
> Feel free to send it my way.
>>
>> Help!!
>>>
>>> btw, here are a couple of interesting datapoints:
>>>
>>> 1. I have breakpoints in jsf.ajax.request and jsf.ajax.response. The
>>> request breakpoint is hit, but the response is not. The return status
>>> for the response is 200, so there are apparently no errors.
>>>
>>> 2. I thought, from Jim Driscoll's blog about f:ajax, that we had to
>>> specify client ids for execute and render, so I originally had this:
>>>
>>> <f:ajax execute="@this" render="#{cc.clientId}:image"/>
>>>
>>> But when I do that, I get this error...
>>>
>>> <f:ajax> contains an unknown id
>>> 'j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image'
>>>
>>>
>>> ...when I load the page, even though that is the correct client id
>>> (as evidenced from the request data above). Evidently, we're supposed
>>> to use the component id and not the client id?
>>
>> When specifying execute/render ids for <f:ajax>, the id resolution
>> behavior is similar to findComponent(). So, if you specify a
>> relative id, eg. "image", this should be resolved relative to the
>> nearest naming container. In your case, that would be the
>> composite component. In order to specify an absolute id, you would
>> prefix the id with ":", eg. ":foo:mycompositecomp:image".
>>
>>
>> Ah, okay, I missed that in the docs. Thanks for the explanation.
>>
>>
>> david
>
>
>