[jsr-314-open-mirror] [jsr-314-open] question regarding ajax update cycle

[Alexander Smirnov]

You have to keep in mind that JSF Ajax updates component content, not
the Html elements. Therefore, any component have to has enclosing Html
element ( <div> , <span> whatever else ) with id attribute generated as
the component clientId to be compatible with Ajax. In your case, you
have to create placeholder element ( probably <div> ) that encapsulates
both of your elements.

On 04/06/2010 09:42 AM, Werner Punz wrote:
> Hello everyone, I ran into an issue regarding the update, which is
> closely related to a behavior jsf2 exposes regarding component rendering
> in the update cycle.
> 
> The main issue is following: If we have a component which we trigger
> with following code:
> 
>  <myComp:javascriptTestComponent
> id="myTestComponent"></grv:javascriptTestComponent>
>                 <a href="#" name="mego3"
>                   
> onclick="jsf.ajax.request(this,event,{execute:'myTestComponent',
> render:'myTestComponent'}); return false;">submit
>                     me</a>
> 
> and the component itself renders following in its renderer:
> 
>         ResponseWriter writer = context.getResponseWriter();
>         writer.startElement(DIV, component);
>         writer.writeAttribute(ID,component.getClientId(context), null );
>         writer.write("hello world"+Math.random());
>         writer.endElement(DIV);
> 
>         writer = context.getResponseWriter();
>         writer.startElement(DIV, component);
>        
> writer.writeAttribute(ID,component.getClientId(context)+":_second", null );
>         writer.write("hello world"+Math.random());
>         writer.endElement(DIV);
> 
> 
> the resulting ppr response now looks like following:
> 
> |<update id="myTestComponent">
> 
> <![CDATA||[<div id="myTestComponent">hello world0.8619488403376933</div>
> <div id="myTestComponent:_second">hello|| world0.25176272071402683</div>]]>
> 
> </update>...|
> 
> Now the problem is, since the update part of the response is already
> opened the component author cannot really influence the response
> rendering in any meaningful way (the correct solution would be to issue
> two update commands here)
> Now the javascript has to react on the client side to resolve that
> situation.
> 
> Now MyFaces just replaced the original
> 
> |myTestComponent|
> 
> with the update code and hence the result was a div wandering down (aka
> wrong update)
> 
> hello world0.48748236239247755
> hello world0.6020541783857698
> hello world0.7181842402648805
> hello world0.2803064696069696
> (after a handful of requests, with the lowest line being the first
> second div being dran)
> 
> now due to being incorrect a user gave me rightfully a bug issue. I dug
> deeper and ran the same example
> against Mojarra, now Mojarra does cherry pick the delivered first div
> and replaces the original div, and omits the second one.
> The Problem is Mojarra just does it for newer browsers, it does the same
> just updating the  original element with the replacement code
> (and hence producing a wandering div) for IE6+7-
> 
> My question is, first, how to handle that problem correctly. Secondly,
> is this even a problem for us or more one for the component author?
> In the end the main problem would not exist if they ajax api could be
> used on the component side properly without being enforced already into
> an update (or to allow nested updates, inserts within an update)
> 
> 
> Werner
>