[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