Re: cdata escaping in ajax response

[Sven Meier]

Hi Martin,

>Any reference to the recommendation?
well, Google says so:

    https://www.google.de/search?q=xml+nested+cdata

... and Wikipedia does:

    https://en.wikipedia.org/wiki/CDATA#Nesting

>Why "]]" + "]]><![CDATA[" + ">" is not just "]]]]><![CDATA[>"?

I just wanted to explain the meaning of all these braces.

>I guess the reason is that this is really old code

That's what I though by looking at the history - it seems to have been 
that way since day one of ajax support.

Thanks
Sven


On 25.06.2015 21:59, Martin Grigorov wrote:
Hi Sven,

On Thu, Jun 25, 2015 at 4:08 PM, Sven Meier <s...@meiers.net> wrote:

Hi all,

currently AjaxRequestHandler escapes CDATA as follows:

     Strings.replaceAll(str, "]", "]^")

decode() in wicket-ajax-jquery.js does the inverse on processing of the
ajax response:

     replaceAll(text, "]^", "]")

But the recommended approach to handle nested CDATA sections is to split
each "]]>" with an additional CDATA end/start:

Any reference to the recommendation?


     Strings.replaceAll(str, "]]>", "]]" + "]]><![CDATA[" + ">");

Did you skip some part(s) here?
Why "]]" + "]]><![CDATA[" + ">" is not just "]]]]><![CDATA[>"? Why is
needed the concatenation?


Does anybody know why we don't do it this way?

I guess the reason is that this is really old code that worked well so far.


The nice thing about the latter solution is that wicket-ajax-jquery.js
doesn't have to know anything about escaping, because the XML parser will
automatically take care of it.

I don't mind doing the change.
I think there are JS tests for the current way. Please replace them with
tests which parse mock response with the new approach.


Thanks
Sven