He cannot really uses the partialresonsewriterimpl, because he rolls his
own custom ppr protocol, but he also has to add the fixups we did for
the ppr responsewriter (were control over cdata blocks were removed from
the users hands to some degree)
The fixup is relatively easy but induces a speed hit because you have to
double escape embedded ]]> blocks via regexps since the xml spec clearly
says that a CDATA block has to end with ]]> and non ]]> is allowed in
between.
Werner
Am 12.07.10 16:41, schrieb Bruno Aranda:
The bug seems to be that primefaces tries to use the
HtmlResponseWriterImpl instead of the PartialResponseWriterImpl...
Bruno
On 12 July 2010 15:28, Bruno Aranda<[email protected]> wrote:
Yes, it looks to me like the same thing. That is the thread in the
primefaces forum:
http://primefaces.prime.com.tr/forum/viewtopic.php?f=3&t=3265&p=15035
On 12 July 2010 15:21, 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>
