Re: [jsr-314-open-mirror] [jsr-314-open] question regarding ajax update cycle
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