11:42 a.m.
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
5:05 p.m.
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
5:17 p.m.
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(a)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
>
2:26 a.m.
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(a)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(a)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
4:15 a.m.
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(a)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(a)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(a)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
4:38 a.m.
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(a)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(a)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(a)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(a)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
5:28 a.m.
Hi,
I agree with Alexander. The component you posted is not well designed. As Alexander
pointed out: What would getClientId() return for this component? I also agree with
Alexanders solution: enclose the components reposne with a div that carries a proper
clientId.
It's an obvious characteristic of JSF AJAX to require having one HMTL element
corresponding with one JSF component to be able to replace it via AJAX. Trying to craft a
sophisticated solution for the cornercase of a badly designed component leads to a highly
complicated specification enhancement that only makes sense to very few experts.
Best regards,
Ganesh
Martin Marinschek schrieb:
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(a)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(a)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(a)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(a)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
>>
--
"There are two kinds of people in the world, those who believe there are two kinds of
people and those who don't."
— Robert Benchley
5:52 a.m.
Hi,
I agree with Ganesh and Alexander.
All components in PrimeFaces have an enclosing container element (span or div) with a
proper client id assigned as well.
Regards,
Cagatay
On Apr 7, 2010, at 11:28 AM, Ganesh wrote:
Hi,
I agree with Alexander. The component you posted is not well designed. As Alexander
pointed out: What would getClientId() return for this component? I also agree with
Alexanders solution: enclose the components reposne with a div that carries a proper
clientId.
It's an obvious characteristic of JSF AJAX to require having one HMTL element
corresponding with one JSF component to be able to replace it via AJAX. Trying to craft a
sophisticated solution for the cornercase of a badly designed component leads to a highly
complicated specification enhancement that only makes sense to very few experts.
Best regards,
Ganesh
Martin Marinschek schrieb:
> 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(a)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(a)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(a)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(a)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
>>>
--
"There are two kinds of people in the world, those who believe there are two kinds
of people and those who don't."
— Robert Benchley
7:26 a.m.
It is not well designed but yet a valid component (as I said the issue
originated from an issue I got for myfaces and I gave also the root node
recommendation), as I said both approaches are broken, but an error
definitely has to be emitted in this case, I will do that on the client side
and warn the author of the component that it has to habe a root node with
the client id!
After all we have the error API in place, why not use it a little bit more
:-)
Also the spec clearly does just say that the code part with the client id
has to be replaced with the content of the CDATA block afair!
The main issue I have with the old approach compared to mojarras and our
newer approach
is, that if you just update the client id with the code junk coming in from
the client without taking the clientid itself into consideration you end up
with a broken dom tree, aka a dom tree with multiple nodes having the same
id, hence the behavior definitely is more broken in the old way than in the
new way.
The probably cleanest solution probably would be to stop the dom tree update
(and dont update) or leave the affected part blank, or with something which
signals that the area could not be updated due to the problem and raise the
error.
As for exposing the PartialResponseWriter API to the components in myfaces
only, this does not make sense too much it would bind the components to the
impl and I am not sure what the status about the approach is which hopefully
will go into 2.1. This needs to be fixed on the API side and should have
been before 2.0 went into production but that did not happen, probably
because it was too late when this issue was discovered.
Werner
On Wed, Apr 7, 2010 at 12:28 PM, Ganesh <ganesh(a)j4fry.org> wrote:
Hi,
I agree with Alexander. The component you posted is not well designed. As
Alexander pointed out: What would getClientId() return for this component? I
also agree with Alexanders solution: enclose the components reposne with a
div that carries a proper clientId.
It's an obvious characteristic of JSF AJAX to require having one HMTL
element corresponding with one JSF component to be able to replace it via
AJAX. Trying to craft a sophisticated solution for the cornercase of a badly
designed component leads to a highly complicated specification enhancement
that only makes sense to very few experts.
Best regards,
Ganesh
Martin Marinschek schrieb:
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(a)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(a)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(a)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(a)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
>>>
>>>
>
>
--
"There are two kinds of people in the world, those who believe there are
two kinds of people and those who don't."
— Robert Benchley
6:56 p.m.
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(a)apache.org <mailto:mmarinschek@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(a)gmail.com
<mailto: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(a)exadel.com <mailto: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
>> >
>>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
1:58 a.m.
On Tue, Apr 13, 2010 at 1:56 AM, Alexander Smirnov <asmirnov(a)exadel.com> wrote:
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.
I agree. The API should be there. And for now, we should present an
error for the broken cases.
best regards,
Martin
2:46 p.m.
Ok probably too late to fix that for myfaces 2.0 but I will get the fixup in
for a post 2.0 release (since this is more or less cosmetic for normal root
element usecases I dont see any problem by postponing the fix)
with a clear error mesage.
In either case, both Mojarra as well as myfaces are broken in this area,
while I have the feeling that Mojarras behavior is more broken by being
inconsistent between IE and the rest of the world :-(
Werner
On Tue, Apr 13, 2010 at 8:58 AM, Martin Marinschek
<mmarinschek(a)apache.org>wrote:
On Tue, Apr 13, 2010 at 1:56 AM, Alexander Smirnov
<asmirnov(a)exadel.com>
wrote:
> 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.
I agree. The API should be there. And for now, we should present an
error for the broken cases.
best regards,
Martin
7:32 a.m.
Ok I posted an issue with the problem and solution under bug #785 in the
spec issue database so that it is not lost.
Werner
On Tue, Apr 13, 2010 at 9:46 PM, Werner Punz <werner.punz(a)gmail.com> wrote:
Ok probably too late to fix that for myfaces 2.0 but I will get the
fixup
in for a post 2.0 release (since this is more or less cosmetic for normal
root element usecases I dont see any problem by postponing the fix)
with a clear error mesage.
In either case, both Mojarra as well as myfaces are broken in this area,
while I have the feeling that Mojarras behavior is more broken by being
inconsistent between IE and the rest of the world :-(
Werner
On Tue, Apr 13, 2010 at 8:58 AM, Martin Marinschek <mmarinschek(a)apache.org
> wrote:
> On Tue, Apr 13, 2010 at 1:56 AM, Alexander Smirnov <asmirnov(a)exadel.com>
> wrote:
> > 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.
>
> I agree. The API should be there. And for now, we should present an
> error for the broken cases.
>
> best regards,
>
> Martin
>
8:39 a.m.
Sorry for reopening this again:
Ok after rereading the spec and reiterating the problem again I came to the
same conclusion as Ganesh and Alex here.
Everything which is in the CDATA blocks in update must be considered to be
part of the update.
so if a component author uses some kind of decoration around the
<placeholder id="clientId> part then he has to be aware of the implications.
I cannot really throw an error here however if the author does not follow
the pattern, due to not being specified and due to having valid usecases to
do this (mostly to embed some javascript which should get triggered rightly
after the update is done but before the entire ajax processing is finished)
So I will revert my original mojarra identical behavior to the one which I
had originally, which is more or less exactly the behavior the spec says and
what you can get within mojarra under IE as well (whatever Mojarra had for
the fixup of this problem fails on IE anyway)
Werner
On Wed, Apr 14, 2010 at 2:32 PM, Werner Punz <werner.punz(a)gmail.com> wrote:
Ok I posted an issue with the problem and solution under bug #785 in
the
spec issue database so that it is not lost.
Werner
On Tue, Apr 13, 2010 at 9:46 PM, Werner Punz <werner.punz(a)gmail.com>wrote:
> Ok probably too late to fix that for myfaces 2.0 but I will get the fixup
> in for a post 2.0 release (since this is more or less cosmetic for normal
> root element usecases I dont see any problem by postponing the fix)
> with a clear error mesage.
> In either case, both Mojarra as well as myfaces are broken in this area,
> while I have the feeling that Mojarras behavior is more broken by being
> inconsistent between IE and the rest of the world :-(
>
> Werner
>
>
>
> On Tue, Apr 13, 2010 at 8:58 AM, Martin Marinschek <
> mmarinschek(a)apache.org> wrote:
>
>> On Tue, Apr 13, 2010 at 1:56 AM, Alexander Smirnov <asmirnov(a)exadel.com>
>> wrote:
>> > 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.
>>
>> I agree. The API should be there. And for now, we should present an
>> error for the broken cases.
>>
>> best regards,
>>
>> Martin
>>
>
>
5346
days inactive
5373
days old
jsr-314-open-mirror@lists.jboss.org
13 comments
5 participants
participants (5)
-
Alexander Smirnov -
Cagatay Civici -
Ganesh -
Martin Marinschek -
Werner Punz