[TYPO3-core] RFC #9779: t3lib_div::trimExplode limit parameter leads to wrong result with non-empty requirement
Franz Holzinger
franz at ttproducts.de
Tue Mar 3 14:04:13 CET 2009
Hello Benjamin,
>> Your patch will force a complete explode in all cases.
> Yes, but I think that this is the correct behaviour (or let's put it
> this way "expected behaviour" for all of the). If you want to clean
> trimmed items and you want a maximum number of items, you need this
> solution.
>
> Imagine ",,,,anc2,sr2,,str3" and you get an empty array after removing
> trimmed items with a limit of 3.
But an additional leading IF could consider also this case in order not
to slow its execution speed down. This is why the §limit parameter is
used at all, to have a benefit in speed.
> If you have a very long string and you need that (unusual) behaviour,
> it'd make more sense to do a manual explode with a limit and an implode
> again before you let it run through the trimExplode.
In the former versions of TYPO3 the execution speed has been almost the
same for explode or t3lib_div::trimExplode. The parameter
$onlyNonEmptyValues won't be needed in many cases. This function is
normally called to trim a big list of parameters entered in TypoScript.
> Do you have a use-case for that scenario?
You could want to get the first 3 lines out of a long text string read
in from a file and explode it over the "\n" return character. And then
display it without leading or trailing spaces. The first lines normally
contain header information.
- Franz
More information about the TYPO3-team-core
mailing list