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

[Martin Marinschek]

Hi guys,

is it really useful to follow Mojarra's behaviour here? I think it
might be a little better to have a wandering div (and see that
something is wrong) than just ignoring the second div and with this
let the developer in the believe that everything is alright, which it
really isn't.

best regards,

Martin

On 4/7/10, Werner Punz <werner.punz at gmail.com> wrote:
> Yes that is what I was basically posting as workaround to the issue I got,
> nevertheless I now coded Mojarras behavior into MyFaces, just to be
> consistent here.
> (With the exception that I also fixed it on the IE side as Mojarra behaves
> for
> more compliant  browsers to have the same behavior over all browsers)
>
> I do not expect any component author really doing it differently than you
> said, Alex, but in the end to really resolve the problem we probably have to
> resolve the enforced update issue in the long run so that the
> PartialResponseWriter API can be used in its full extent and glory by the
> component authors instead of being shoehorned into an already open update
> tag!
>
> Werner
>
>
> On Wed, Apr 7, 2010 at 12:05 AM, Alexander Smirnov
> <asmirnov at exadel.com>wrote:
>
>> 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
>> >
>>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces