Hi Werner, no. Don't follow any broken approach - emit an error saying that this is not possible. Then the component author will know. Mojarra should do the same.
I agree that the API should be more open than. Can we expose this API unilaterally at least in MyFaces? best regards, Martin On 4/7/10, Werner Punz <werner.p...@gmail.com> 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>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> 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>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 >> > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces