Bug #82007: Inconsistent variable value for f:variable viewhelper for integer 0 - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #82007

closed

Inconsistent variable value for f:variable viewhelper for integer 0

Added by Michael Stopp almost 7 years ago. Updated almost 7 years ago.

Status:

Closed

Priority:

Must have

Assignee:

Category:

Fluid

Target version:

Start date:

2017-07-31

Due date:

% Done:

Estimated time:

TYPO3 Version:

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

If I do this in a template (Fluid 8.4.7):

<f:variable name="zero1" value="0" />
{f:variable(name: 'zero2', value: 0)}
<f:debug>{zero1}</f:debug>
<f:debug>{zero2}</f:debug>

When I first call this, the output is:

0 (integer)
0 (double)

After simply reloading the browser, the output becomes:

NULL
NULL

The problem goes away, if I use the f:cache.disable VH to output the variables, so it must obviously be a cache-related issue.
If I set a variable to 0 in the controller and pass it to the view, it works consistently.
(BTW, the problem is the same when using the variable VH of VHS.)

A propos consistency: it's not really the issue here, but it seems a bit odd that the tag and inline notation don't produce the exact same result here (integer vs. double); I don't know if that's by design or by mistake...

Actions

Copy link

Updated by Claus Due almost 7 years ago

I can explain why those two expressions give different results. The "problem" here in a nutshell is that two different expressions and two different treatments get applied to the value:

In tag mode, the value is always considered a string and is trimmed for quotes, then checked if it is numeric and if so, a NumericNode is created (without casting the value). NumericNode internally does not explicitly cast, but rather adds zero to the value. This preserves the initial type and if the passed value is a string containing a zero, adding a zero to it creates an integer.
In inline mode, the value is part of an array expression and a different detection routine is used to detect hardcoded numbers (and only those; e.g. not numbers coming from a variable!). This matches your case and the result of such a match is actually cast to (float) by the TemplateParser (the input is also a string). But contrary to tag mode, using a number in an array does not create a NumericNode and the add-zero pseudo-casting does not happen.

Phew. I hope that's understandable without knowing the internals.

This explains why you end up with two different data types in your particular case, and it is by design in both cases but two different solutions were chosen (the float cast is very old - the add-zero in NumericNode is fairly new). And you can certainly make the argument that this should be uniform - which I would say should be done by doing the same add-zero trick in TemplateParser instead of as it is now, casting the value to a float (which then becomes a double internally in PHP).

Actions

Copy link