TYPO3 / Fluid

Fluid template rendering engine - Standalone version
GNU Lesser General Public License v3.0
152 stars 93 forks source link

NamespaceDetectionTemplateProcessor removes CDATA sections #474

Open ghost opened 5 years ago

ghost commented 5 years ago

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 commented 5 years ago

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 commented 2 years ago

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 978071f8f5484e01882d7c4c6d740064f22d51ef, and was first released with fluid v1.0.0

sandrotanner commented 1 year ago

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 commented 1 year ago

@sandrotanner The 3.0-experimental branch won't be continued, see https://github.com/TYPO3/Fluid/issues/591

sandrotanner commented 1 year ago

@sandrotanner The 3.0-experimental branch won't be continued, see https://github.com/TYPO3/Fluid/issues/591

thanks 👍