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
>
