It's a little bit lame that the primefaces guys never run their tests
with MyFaces.
-Matthias
On Mon, Jul 12, 2010 at 7:21 AM, Marcus Büttner <m...@buett.at> wrote:
> Hi,
>
> I've a similar problem with primefaces and myfaces. The standard <f:ajax> to
> rerender a component works as espected but <p:ajax> do not update other
> primefaces components. I've posted it to the primefaces forum but with
> mojarra it seems to work.
>
> my example:
>
> <h:form id="myForm">
> <h:selectOneMenu id="selectMenu" value="#{myBean.menuValue}">
> <f:selectItem itemValue="true" itemLabel="Yes"/>
> <f:selectItem itemValue="false" itemLabel="No"/>
> <p:ajax event="change" update="output" process="selectMenu"/>
> </h:selectOneMenu>
> <p:inputMask id="output" mask="" value="#{myBean.menuValue}"/>
> <h:commandButton action="action"/>
> </h:form>
>
> Could this be the same cause?
>
> Marcus
>
> Bruno Aranda schrieb:
>>
>> I think you may be right, I have tried to test cases (attached to the
>> JIRA ticket). One using a primefaces button and the other using a jsf
>> standard button, and the latter works as expected.
>>
>> Bruno
>>
>> On 12 July 2010 15:03, Werner Punz <werner.p...@gmail.com> wrote:
>>
>>>
>>> Superb, as I said I am not entirely sure if myfaces is at fault here, my
>>> personal guess goes towards a custom partial response writer on the
>>> PrimeFaces side, but I am guessing here, because we have fallback code in
>>> our ppr responseWriter which exactly should cover what we have here:
>>>
>>> private String postProcess(StackEntry currentElement) throws
>>> IOException
>>> {
>>>
>>> currentElement.getWriter().flush();
>>> StringBuffer buffer = currentElement.getDoubleBuffer().getBuffer();
>>>
>>> String resultString = buffer.toString();
>>> //section http://www.w3.org/TR/REC-xml/#sec-cdata-sect everything
>>> is
>>> parsed
>>> //until it hits a ]]> hence we need to do some mapping here
>>>
>>> //ok since our maximum string size is Integer.MAX_VALUE (most JVMs
>>> use char [] as
>>> //representations
>>> //we can work on strings directly, instead of having to go through
>>> streams
>>> //it is absolutely unlikely that we will ever have a buffered
>>> stream
>>> bigger than that
>>> //for our writer!
>>> if (resultString.contains("]]>")) {
>>>
>>> //we now first remove pending javascript CDATA blocks
>>> //the reason is if we leave them the ppr chokes on them
>>> //the syntax from the auto generated CDATA usually is
>>> //\s+<![CDATA[
>>> resultString =
>>> resultString.replaceAll("//\\s*((\\<\\!\\[CDATA\\[)|(\\]\\]\\>))", "");
>>> //now to fullfill the xml spec we have to replace all ]] with
>>> blocks of cdata
>>> resultString = resultString.replaceAll("\\]\\]\\>",
>>> "]]><![CDATA[]]]]><![CDATA[>");
>>> }
>>> return resultString;
>>> }
>>>
>>> The idea is to double buffer a ppr cdata block and do some final
>>> postprocessing by excaping ]]> by valid cadata escapes.
>>> So this section should never be rendered that way
>>>
>>>>>>>
>>>>>>> //]]></script>
>>>>>>>
>>>
>>> would have been crrect
>>> ]]><![CDATA[]]]]><![CDATA[></script>
>>>
>>> instead it should have gotten a split into two cdata blocks.
>>> But we may have a bug here as well.
>>>
>>> Werner
>>>
>>>
>>>
>>>
>>> Am 12.07.10 15:52, schrieb Bruno Aranda:
>>>
>>>>
>>>> I will create a simple test case,
>>>>
>>>> Cheers,
>>>>
>>>> Bruno
>>>>
>>>> On 12 July 2010 14:47, Werner Punz<werner.p...@gmail.com> wrote:
>>>>
>>>>>
>>>>> Hi Bruno can you file a snippet of the original xhtml markup into
>>>>>
>>>>> https://issues.apache.org/jira/browse/MYFACES-2811
>>>>>
>>>>> Werner
>>>>>
>>>>>
>>>>>
>>>>> Am 12.07.10 15:33, schrieb Werner Punz:
>>>>>
>>>>>>
>>>>>> Hi Bruno, please file a bugreport on it. We should fix this before
>>>>>> 2.0.1
>>>>>> this is a bug in the ppr responsewriter on the server side. I was
>>>>>> fixing
>>>>>> exactly this issue a few months ago, maybe we have some regression bug
>>>>>> here.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Werner
>>>>>>
>>>>>> Am 12.07.10 14:48, schrieb Bruno Aranda:
>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have a partial response that contains invalid syntax because CDATA
>>>>>>> sections are nested. For example, in my app this code is generated in
>>>>>>> the partial response:
>>>>>>>
>>>>>>> <?xml version="1.0"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> encoding="UTF-8"?><partialResponse><components><component><id>editorForm</id><output><![CDATA[<form
>>>>>>>
>>>>>>> id="editorForm" name="editorForm" method="post"
>>>>>>> action="/editor/curate/publication.jsf?conversationContext=2"
>>>>>>> enctype="application/x-www-form-urlencoded"><span
>>>>>>> id="growl"></span><script type="text/javascript">//<![CDATA[
>>>>>>> jQuery.gritter.add({title:'Publication saved',text:'AC:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> EBI-2637354',image:'/editor/primefaces_resource/2.0.3-SNAPSHOT/primefaces/growl/assets/info.png?conversationContext=2',sticky:false});
>>>>>>>
>>>>>>>
>>>>>>> //]]></script>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
