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>
