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

[Alexander Smirnov]

Surely, the API should be available for component developers. Some
components need to update its own part only - for example, tree has to
manage expand/collapse events, or table that able to append or delete
particular rows.

On 04/07/2010 02:15 AM, Werner Punz wrote:
> The problem here is either behavior is wrong (not sure which is
> wronger), in the end the only real fix is to expose the full
> partialresponse writer API to the component author to give him full
> access on how his subpart on the page gets updated.
> 
> This road currently is blocked simply by enforcing an open update tag on
> the components from the rendering lifecycle!
> 
> The workaround is to make the component authors aware that for the PPR
> case within a component they always should make a root node which has
> the identifier of ClientId and embed their own rendering into this root
> node (div, span, whatever)
> 
> So if I follow a broken approach I personally prefer to use the one
> which is consistent over all two implementations.
> 
> In the end the only fix I know which makes sense to this problem is to
> add a marker interface to the spec
> something like PPRAware and a separate component renderer method, renderPPR
> and then adding placeholders for the component while the update tag is
> open, defer the rendering of the PPRAware component to the stage when
> update is closed
> and then render those deferred components by giving them control over
> the update, insert etc... possibilities wie theoretically have in the
> API and practically can only use outside of the render cycle :-(
> 
> 
> 
> 
> On Wed, Apr 7, 2010 at 9:26 AM, Martin Marinschek
> <mmarinschek at apache.org <mailto:mmarinschek at apache.org>> wrote:
> 
>     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
>     <mailto: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 <mailto: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
> 
>