> > 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 <[email protected]> > Antwort an: JSR 314 Open Mailing list <[email protected]> > An: [email protected] > Referenzen: <[email protected]> > <[email protected]> > <[email protected]> > > > > On 5/12/09 2:17 PM, David Geary wrote: >> >> 2009/5/12 Andy Schwartz <[email protected] >> <mailto:[email protected]>> >> >> 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
