Feature #62593
closed
flexible templating: usage of glue-separated list in f:for
0%
Description
I want to convert from a comma-separated list into an array.
I want to use that array in a FOR-object Fluid-templates - for example to generate a list of links.
The comma separated list should be maintainable in the constants editor of the TYPO3-backend, because I collect all specific website-parameters in the constants.
Unfortunately, I can not convert a string to an array in the f:for-Object (TYPO3 6.2.6).
I currently use the following work-around using the VHS-extension: (I don't not need that extension otherwise):
Example:
<f:for each="{v:iterator.explode(content: '{lib_config ->f:format.raw()}', glue: ',')}" as="value">
<f:uri.page pageUid="{value}" additionalParams="{L:'1'}" /><br />
</f:for>
Updated by Claus Due over 8 years ago
- Status changed from New to Rejected
Sorry to reject this one Dieter, but hopefully you'll agree:
While it would be convenient to be able to do this for the people that are very comfortable with Fluid, it has a great likelihood of breaking if you use any sort of complex ViewHelper expression in the `each` argument - like you do above. Basically, any error in the expression would cause the ViewHelper to receive a string without any explanation why, no stack trace or anything - and worse still, just causing unexpected output and potentially breaking subsequent usages of expected objects with no indication of the original cause of the problem.
However: it has on many occasions been discussed whether or not the core itself needs `explode` and `implode` ViewHelpers. I don't personally have any objection to either (except if placed in the "format" scope instead of "iterator" which was carefully chosen to not cause any problems for humans as well as PHP). We'd welcome a feature request to add those, but please create that as a new feature request. Or maybe even open it as a request for the standalone Fluid package - https://github.com/TYPO3Fluid/Fluid - which will soon be the base of Fluid in TYPO3 as well. We'd be happy to implement.
Closing as "rejected" because the very specific feature requested in this issue is rejected due to potentially unpredictable and hard to debug behavior; plus suggested alternative feature request and location for request.