myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Aranda <brunoara...@gmail.com>
Subject Re: Problem with nested CDATA sections in scripts in a PPR
Date Mon, 12 Jul 2010 14:08:29 GMT
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.punz@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.punz@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>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>

Mime
View raw message