-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] SplitViewHelper #856
Conversation
TBH I see multiple viewhelpers / syntax features here:
IMO this should be split accordingly to have small composable parts which could be chained:
Notice that "iterator" would be a better NS here to hint at the subject type these viewhelpers operate on. The actually do not perform formatting (convert to string) as known in Fluid so far. |
My two cents: (Preface: Generally I'm not an advocate of using too much logic in fluid templates. The complexity/barrier should be low, so that integrators without too much coding knowledge can find their ways.) I can see a need for converting a string to an array (for iteration) or the other way round (joining an array) so that this data can easily be passed to data-attributes or javascript-calls, where integrators have no ability/entrypoint to do that within a Controller or Service. While the chaining is cool for developers, I'm afraid it adds too much cognitive complexity to a task, where integrators are more accustomed to specifying parameters (like "nonEmpty=true" and whathaveyou). A chained syntax looks a bit like map/reduce, which developers may find easy to read, but can create panic for "normal people"? I think to stay within the "format" namespace would better suit established knowledge, where people search for any string transformations in that scope? TYPO3-fluid uses "transform" which would also fit somehow, but it's current application is focussed at HTML and not array/string conversion. Closing note: Please do use the keywords "implode" and "explode" in the ViewHelper description, so that PHP developers can easily find the viewhelper (I myself wouldn't search for "split"). |
Indeed, the input is not an iterator, so the NS should actually be |
How about:
IMO "formatting" would still fit, because I "format a string as array", and would use a well-known namespace. (Filed under: There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors) |
Please let us avoid mistakes of the past and not add more bloat to our templates for base-level functionality. |
Can you be more specific? What is unnecessary? What should and shouldn't the VH support? |
@s2b it´s about the placement debate not about the functionality.
|
Maybe we should also take some inspiration from Twig here: https://twig.symfony.com/doc/3.x/filters/index.html The similarly have |
we almost need all of those, added the join on https://review.typo3.org/c/Packages/TYPO3.CMS/+/83442 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we continue this style, every view-helper is responsible for everything. We should stay to the basics. See twig or JS prototype implementation.
value -> split(separator, limit)
Our current "manipulation" viewhelpers all use the "format" hierarchy, and in the main hierarchy we only have quite specific structural/operational helpers:
When we add "data/string/array manipulation" to that main level, it may become odd for integrators why one is in "format" and the other is not...? I agree, adding a new top level hierarchy feels like "too much". In that case I'd opt for using the "format" namespace though, to keep documentation and expectations in line. |
Thank you all for this helpful feedback. Now that I have a better overview of the different opinions about this, I can get started with other ViewHelpers as well. Summary:
For this ViewHelper, I will adjust the following:
I will think a bit more about the folder structure discussion as well as the consequences of changing it (like VH documentation, backwards compatibility, ...). |
54910ac
to
562b198
Compare
I've uploaded a new version. I moved the VH to the root folder and removed all arguments except for |
The SplitViewHelper splits a string by the specified separator, which results in an array. The number of values in the resulting array can be limited with the limit parameter, which results in an array where the last item contains the remaining unsplit string. This ViewHelper mimicks PHP's :php:`explode()` function. Split with a separator: ```xml <f:split value="1,5,8" separator="," /> <!-- Output: {0: '1', 1: '5', 2: '8'} --> ``` Split using tag content as value: ```xml <f:split separator="-">1-5-8</f:split> <!-- Output: {0: '1', 1: '5', 2: '8'} --> ``` Split with a limit: ```xml <f:split value="1,5,8" separator="," limit="2" /> <!-- Output: {0: '1', 1: '5,8'} --> ```
562b198
to
a78d642
Compare
This patch adds a new <f:format.split> ViewHelper to Fluid Standalone. It is named "split" instead of "explode" to be consistent with the naming of JavaScript.
The ViewHelper aims to support everything that TYPO3's utility functions "GeneralUtility::intExplode()" and
"GeneralUtility::trimExplode()" provide.
In a following patch, its counterpart "join" will be added.