On 4/7/10, Werner Punz <
werner.punz@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@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
>> >
>>
>