On Wed, May 13, 2009 at 8:12 PM, Matthias Wessendorf <[email protected]> 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 <[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
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Reply via email to