2009/5/15 Werner Punz <werner.p...@gmail.com
<mailto:werner.p...@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.lu...@sun.com
<mailto:ryan.lu...@sun.com>>
Antwort an: JSR 314 Open Mailing list <jsr-314-o...@jcp.org
<mailto:jsr-314-o...@jcp.org>>
An: jsr-314-o...@jcp.org <mailto:jsr-314-o...@jcp.org>
Referenzen:
<75fa9e650905120936p114faae7g987969d2e0b7c...@mail.gmail.com
<mailto:75fa9e650905120936p114faae7g987969d2e0b7c...@mail.gmail.com>>
<4a09adcc.8040...@oracle.com
<mailto:4a09adcc.8040...@oracle.com>>
<75fa9e650905121417h7e0b4758obbd3de65a428c...@mail.gmail.com
<mailto:75fa9e650905121417h7e0b4758obbd3de65a428c...@mail.gmail.com>>
On 5/12/09 2:17 PM, David Geary wrote:
2009/5/12 Andy Schwartz <andy.schwa...@oracle.com
<mailto:andy.schwa...@oracle.com>
<mailto:andy.schwa...@oracle.com
<mailto:andy.schwa...@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.b...@j4fry.org <mailto:alexander.b...@j4fry.org>
Webprofil: http://www.j4fry.org/alexanderbell.shtml
