[jsr-314-open-mirror] [jsr-314-open] question regarding ajax update cycle
Martin Marinschek
mmarinschek at apache.org
Wed Apr 7 05:38:46 EDT 2010
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.punz at 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
> <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> 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
>>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
More information about the jsr-314-open-mirror
mailing list