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.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
--
"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
