Bug #8879
{ } when using as JavaScript
| Status: | Closed | Start date: | 2010-07-15 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - | |||
| Has patch: | No | Affected Flow version: | (any) |
Description
assuming the following FLUID code:
<f:if condition="foo">
<script type="text/javascript">
var myDemoJSObject = {
key1: 'foo',
key2: 'bar
}
</script>
</f:if>
this is outputted as
<script type="text/javascript">
var myDemoJSObject = Array
</script>
I think the brackets are regarded as inline view helpers and tried to be parsed. Wouldn't it be senseful to require inline view helpers may NOT have a whitespace after the opening bracket, so it should be (regex) /{\w/ and NOT /{./ or something like that.
Related issues
History
#1 Updated by Bastian Waidelich about 5 years ago
- Status changed from New to Closed
Hi Adrian, thanks for your feedback.
This seems to be the same issue as #6338.
Because it would be really difficult to differenciate Fluid brackets from JavaScript brackets automatically you should either extract your script to a js file or wrap your inline scripts like:
<script type="text/javascript">/*<![CDATA[*/ // your scripts /*]]>*/</script>
That's considered best practice anyways.
have a look at #3677 too.
#2 Updated by Adrian Föder about 5 years ago
Hi Bastian,
sorry for that double posting; I didn't find an already existing report similar to mine.
In fact, moving to an external js file is exactly what I would not want, because I have to use ViewHelpers inside my JavaScript:
<script type="text/javascript">
var myTranslations = {
llKeyOne: '{f:translate(key:"myKey")}
};
</script>
This was the thing that triggered my reporting.
But of course JavaScript content should be wrapped in CDATA anyway.
Am I understanding right that inline view helper parsing would NOT take place inside a CDATA section? If so, my approach above to get the translation into javascript would also fail....
So long and best regards.
Adrian
#3 Updated by Bastian Waidelich about 5 years ago
Adrian Foeder wrote:
Hi Adrian,
Am I understanding right that inline view helper parsing would NOT take place
inside a CDATA section?
Exactly. CDATA is the proper (and only) way to comment out Fluids inline notation. So it's kind of similar to the <?php ?> tags in PHP. If you want to mix JavaScript and Fluid, you'll could write
<script type="text/javascript">/*<![CDATA[*/
/*]]>*/
var llKeyOne = '{f:translate(key:"key1")}';
var llKeyTwo = '{f:translate(key:"key2")}';
/*<![CDATA[*/
var myTranslations = {
llKeyOne: llKeyOne,
llKeyTwo: llKeyTwo
};
/*]]>*/</script>
HTH,
Bastian
#4 Updated by Adrian Föder about 5 years ago
Hi Bastian,
but why, and sorry for the question, not make it mandatory to let the namespace identifier immediately follow after the opening bracket:
"valid" inline ViewHelper would be
{f:viewHelperName(attrib:'etc')}
while the "invalid" way were
{ f:viewHelperName(attrib:'etc')}
An opening bracket then is only regarded as inline View Helper when having no white space between the opening bracket and "anything else", or vice versa: if a whitespace (or tab or enter or a char not being alphanumeric) follows the opening bracket it is NOT regarded as inline view helper and therefore not be parsed?
I think such a rule could be legitime (MySQL functions for example must also not contain whitespaces before the opening bracket) and solve the "Javascript" problem...
#5 Updated by Fedir RYKHTIK about 2 years ago
Quite annoying to put the CDATA before and after each JS array. Prefer to have some syntax optimization in Fluid, as {$ or obligatory name space after the bracket opening.
#6 Updated by Bastian Waidelich about 2 years ago
- Has patch set to No
- Affected Flow version set to (any)
Fedir RYKHTIK wrote:
Quite annoying to put the CDATA before and after each JS array. Prefer to have some syntax optimization in Fluid,
as {$ or obligatory name space after the bracket opening.
Do you still have issues with this since #43356 is merged??
Apart from that: You should really outsource all JavaScript to js files. Latest when Content Security Policy is going to be widely used, inline JS won't work any longer
#7 Updated by Fedir RYKHTIK over 1 year ago
Bastian Waidelich wrote:
Do you still have issues with this since #43356 is merged??
Apart from that: You should really outsource all JavaScript to js files. Latest when Content Security Policy is going to be widely used, inline JS won't work any longer
I didn't noticed changes in current LTS version.
Thanks for the link, it's a good reason not to use Inline JS. I'm generating external JS files with Fluid, it's not inline, even if it's Fluid based.