Hi Werner, AFAIK, this hasn't made it into Mojarra.
regards, Martin On 5/16/09, Werner Punz <[email protected]> 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 <[email protected] >>> <mailto:[email protected]>> >>> >>> 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 <[email protected] >>> <mailto:[email protected]>> >>> Antwort an: JSR 314 Open Mailing list <[email protected] >>> <mailto:[email protected]>> >>> An: [email protected] <mailto:[email protected]> >>> Referenzen: >>> <[email protected] >>> >>> <mailto:[email protected]>> >>> <[email protected] >>> <mailto:[email protected]>> >>> <[email protected] >>> >>> <mailto:[email protected]>> >>> >>> >>> >>> On 5/12/09 2:17 PM, David Geary wrote: >>> >>> 2009/5/12 Andy Schwartz <[email protected] >>> <mailto:[email protected]> >>> <mailto:[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 >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Mit freundlichen Grüßen / Kind regards >>> Alexander Bell >>> >>> J4Fry OpenSource Community >>> Internet: http://www.j4fry.org >>> E-Mail: [email protected] <mailto:[email protected]> >>> 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
