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 > <mmarinsc...@apache.org <mailto:mmarinsc...@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.p...@gmail.com > <mailto:werner.p...@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 > > <asmir...@exadel.com <mailto:asmir...@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 > >