Feature #39682
Disregegard { as Fluid variable when followed by a white space
| Status: | Rejected | Start date: | 2012-08-10 | |
|---|---|---|---|---|
| Priority: | Could have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | Core | |||
| Target version: | - | |||
| 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
History
#1 Updated by Alexander Berl almost 3 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 almost 3 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 almost 3 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 almost 3 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 almost 3 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 almost 3 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:
1<script type="text/javascript"> 2var someSetting = "{settings.someSetting}"; 3/* <![CDATA[ */ 4 alert(someSetting); 5/* ]]> */ 6</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 almost 3 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 almost 3 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?