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