Hi Bruno you found out the same thing as I did locally here.
I read the third page
The issue is, that Primefaces rolls out its own partial request/
response mechanism instead of utilizing the jsf2 infrastructure and he
made the same mistake we did originally by relying on the ResponseWriter
to escape ]]> sections in a startCDATA and endCDATA. Now the problem is
that the spec does not enforce this behavior and both impls for speed
reasons left it out per default.
We fixed the issue on the PartialResponseWriter level (and induced a
small speed hit that way), same did Mojarra I guess.
That does not help if the library rolls its own responseWriter and falls
again into the same spec hole - trap.
I have filed all this into the issue, and lets see what comes out of it.
My personal preferrence is to have this fixed first on primefaces level
and if the need arises have this fixed on spec level as well or by
synchronizing both impls in their default behavior in this area.
But in the end Leonardo has the final word on this, he is the core
maintaner.
Werner
Am 12.07.10 16:28, schrieb Bruno Aranda:
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>
