From asmirnov at exadel.com Tue Apr 6 18:09:10 2010 Content-Type: multipart/mixed; boundary="===============4850932898171983299==" MIME-Version: 1.0 From: Alexander Smirnov To: jsr-314-open-mirror at lists.jboss.org Subject: Re: [jsr-314-open-mirror] [jsr-314-open] question regarding ajax update cycle Date: Tue, 06 Apr 2010 15:05:47 -0700 Message-ID: <4BBBB03B.7050402@exadel.com> In-Reply-To: w2w855bfa591004060942rf961168eyadbc0090f9408cb9@mail.gmail.com --===============4850932898171983299== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 (
, 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
) 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: > = > id=3D"myTestComponent"> > = > onclick=3D"jsf.ajax.request(this,event,{execute:'myTestComponent', > render:'myTestComponent'}); return false;">submit > me > = > and the component itself renders following in its renderer: > = > ResponseWriter writer =3D context.getResponseWriter(); > writer.startElement(DIV, component); > writer.writeAttribute(ID,component.getClientId(context), null ); > writer.write("hello world"+Math.random()); > writer.endElement(DIV); > = > writer =3D 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: > = > | > = > hello world0.8619488403376933
>
hello|| world0.25176272071402683]]> > = > ...| > = > 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 >=20 --===============4850932898171983299==--