myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <werner.p...@gmail.com>
Subject Re: [Fwd: Re: f:ajax not working inside composite components?]
Date Sat, 16 May 2009 06:20:12 GMT
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 <mailto:werner.punz@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 <mailto:Ryan.Lubke@SUN.COM>>
>         Antwort an:     JSR 314 Open Mailing list <JSR-314-OPEN@JCP.ORG
>         <mailto:JSR-314-OPEN@JCP.ORG>>
>         An:     JSR-314-OPEN@JCP.ORG <mailto:JSR-314-OPEN@JCP.ORG>
>         Referenzen:
>         <75fa9e650905120936p114faae7g987969d2e0b7ce1d@mail.gmail.com
>         <mailto:75fa9e650905120936p114faae7g987969d2e0b7ce1d@mail.gmail.com>>
>         <4A09ADCC.8040506@oracle.com
>         <mailto:4A09ADCC.8040506@oracle.com>>
>         <75fa9e650905121417h7e0b4758obbd3de65a428c03f@mail.gmail.com
>         <mailto: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>
>             <mailto: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 <mailto:Alexander.Bell@j4fry.org>
> Webprofil: http://www.j4fry.org/alexanderbell.shtml
> 


Mime
View raw message