NamespaceDetectionTemplateProcessor removes CDATA sections

[ghost]

The NamespaceDetectionTemplateProcessor class removes CDATA sections in the template string to avoid parsing their contents. Unfortunately this results in those sections not appearing in the output at all.

One effect for me for example is that some JS code that I wrapped in CDATA (per https://docs.typo3.org/m/typo3/guide-extbasefluid/master/en-us/Fluid/ThingsToKnow/JsAndInline.html) is simply stripped from the HTML.

[NamelessCoder]

Hi @faltrock-abone,

I acknowledge this behaviour, and the fact that it is not correct - but it is almost certainly not going to be fixed, because:

1. This behaviour does not exist in the next major version of Fluid
2. Fixing it in earlier versions constitutes a huge breaking change which will not be allowed in those earlier versions

On a side note: CDATA should be much less necessary in Fluid 3.0 in the first place. In most use cases you will not need to protect the JS in any way; and when you do, it's easily done with a single backslash before a conflicting JS opening curly brace.

[cweiske]

The TYPO3 manual recommends to use CDATA to escape Javascript: https://docs.typo3.org/m/typo3/reference-coreapi/11.5/en-us/ApiOverview/Fluid/Syntax.html#comments

In 2022-08 with TYPO3 v10.4.28 and fluid 2.7.1 I still have this problem here.
It prevents me from having HTML templates that are well-formed in the XML sense, so I can validate them with xmllint.

---

NamespaceDetectionTemplateProcessor was introduced in 978071f, and was first released with fluid v1.0.0

[sandrotanner]

On a side note: CDATA should be much less necessary in Fluid 3.0 in the first place. In most use cases you will not need to protect the JS in any way; and when you do, it's easily done with a single backslash before a conflicting JS opening curly brace.

Is development for Fluid 3.0 still ongoing? If not maybe introducing a non-breaking feature for Fluid 2.x would be super helpful, because even though it may not be a best practice, mixing Fluid and a frontent JS framework in a single file is sometimes the most pragmatic approach to a particular problem in an existing project built around Fluid.

IMHO, the Blade templating engine solves mixing server-side and client-side templating quite elegantly by using @ to suppress server-side-rendering for a single expression: https://laravel.com/docs/10.x/blade#blade-and-javascript-frameworks

Would something like this be possible to implement in Fluid 2.x?
And if backward compatibility were a problem, could there not be a {CurlyBraceEscape on} at the start of the file to "enable" it (similar to {parsing off} that was introduced in #220 )?

[fgeierst]

@sandrotanner The 3.0-experimental branch won't be continued, see #591

[sandrotanner]

@sandrotanner The 3.0-experimental branch won't be continued, see #591

thanks 👍