Feature #39682

Disregegard { as Fluid variable when followed by a white space

Added by Adrian Föder about 9 years ago. Updated about 8 years ago.

Status:
Rejected
Priority:
Could have
Assignee:
-
Category:
Core
Target version:
-
Start date:
2012-08-10
Due date:
% Done:

0%

Estimated time:
Has patch:
No

Description

This is a reopen of an issue I had long time ago, so, long story short:

There's still the need for some CDATA wrapping when it comes to Javascript object notation, ie curly braces in JavaScript sections.

A great advantage, without much drawback, would be to disregard occurrences of braces that are followed by a white space, a tab or a newline. this means,

{f:this(is: 'a valid, regarded fluid variable'}
{so.is.thisVariant}
whereas
{ that: 'is an open brace followed by a whitespace, hence not a fluid variable'}

this maybe could be extended with every character not being \w or so, resulting in

{"alsoThis": "won't be fluid"}

Forcing Fluid syntax do directly follow the opening paranthese is legit in my opinion, you can still do

{f:if(
  condition: 'thisthat',
  then: 'foo',
  else: 'bar'
)};

in MySQL, for example, it's also required to make an open bracket follow the function name immediately: MAX( 5, 2) works, while MAX (5,2) won't.


Related issues

Related to TYPO3.Fluid - Bug #8879: { } when using as JavaScriptClosed2010-07-15

Actions
Related to TYPO3.Fluid - Bug #6338: JSON is being parsed as string ArrayClosed2010-02-04

Actions
#1

Updated by Alexander Berl about 9 years ago

What about Fluid array notation? Would you also unconsider "{ foo: 'bar' }" as invalid array syntax?
IMO that's too much and counter-intuitive, but in my experience also the main problem when fluid syntax is used in Javascript sections (I actually never had a problem with shorthand viewhelper syntaxes).

#2

Updated by Adrian Föder about 9 years ago

yes alex, definitely your example would also be invalid syntax. You then would have to write

{foo: 'bar',
  more: 'true',
  etc: 'pp'
}

or so. This keeps the rule easy: "*stick* your first character to the brace if you want Fluid. End."

#3

Updated by Sebastian Kurfuerst about 9 years ago

  • Status changed from New to Rejected

sorry, I'm strongly against this change going in. Fluid should be whitespace-agnostic.

Instead of introducing these rules, we could make arrays only supported inside Arguments of ViewHelpers, that would also solve most JS clashes.

#4

Updated by Bastian Waidelich about 9 years ago

Hi all,

first I thought "great!" but after thinking about it again, I agree to Sebastians opinion:
Instead of

stick your first character to the brace if you want Fluid

it should be

use CDATA or external files if you want JavaScript in Fluid templates

not only is this recommended anyways, but also the solution only defers the issue to a point where you have something like

foo: {bar:'baz'}

in your script and nothing works suddenly

#5

Updated by Adrian Föder about 9 years ago

great that actually a discussion comes up; Sebastian, no need to sorry, that's why I opened this issue ;)
Sebastian, you brought me to an interesting POV anyways: actually JavaScript really only occurs outside of arguments, hence your suggestion of

make arrays only supported inside Arguments of ViewHelpers

is the exact thing that would be sufficient, because that's the only thing where the problem arises.

Bastian, regarding

use CDATA or external files if you want JavaScript in Fluid templates

I would really like to see an additional option, because especially when attempting to make a Fluid variable part of a JavaScript object notation you'll come up with some heavy, hardly readable "context swapping" with closing and re-opening CDATA blocks.
Could there maybe an additional syntax style for in-javascript ViewHelpers?

But you're right; while writing all this I wonder if it's worth the effort, since currently, if you're aware about how to use Fluid in JS, everything's fine and sufficient...

#6

Updated by Bastian Waidelich about 9 years ago

Adrian Föder wrote:

I would really like to see an additional option, because especially when attempting
to make a Fluid variable part of a JavaScript object notation you'll come up with
some heavy, hardly readable "context swapping" with closing and re-opening CDATA blocks.
Could there maybe an additional syntax style for in-javascript ViewHelpers?

You can always define the Fluid variables before the CDATA:

<script type="text/javascript">
var someSetting = "{settings.someSetting}";
/* <![CDATA[ */
  alert(someSetting);
/* ]]> */
</script>

But even that is deprecated nowadays where you include libraries like jQuery and mootools after the body for performance reasons. Unobtrusive JavaScript used to be best practice, but it's standard practice today I'd say.

#7

Updated by Alexander Berl about 9 years ago

I find the idea of only allowing array syntax in viewhelper arguments interesting. It's at least worth a second thought I guess, as I can't see fluid arrays being used anywhere else.

#8

Updated by Alexander Berl about 9 years ago

I took a short peek and could it be that this could easily leviated by removing the arrayHandler case from the if else switch in
\TYPO3\Fluid\Core\Parser\TemplateParser::textAndShorthandSyntaxHandler?

Also available in: Atom PDF