Well the problem also is on Mojarra, it simply slept through.
Primefaces seems to run its own ajax cycle anyway and for now does not
leverage in this area what jsf2 has to offer otherwise the bug would not
have occurred.
Werner
Am 12.07.10 19:17, schrieb Matthias Wessendorf:
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<[email protected]> 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<[email protected]> 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<[email protected]> 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>
