[TYPO3-core] RFC #16107: Bugfix - listNum = 0 not working anymore due to stdWrap changes

[Jeff Segars]

On 10/24/10 5:22 AM, JoH asenau wrote:
> Susanne Moog wrote:
>> On 22.10.2010 23:54, JoH asenau wrote:
>>> This is an SVN patch request.
>>>
>>> Type: Bugfix
>>>
>>> http://bugs.typo3.org/view.php?id=16107
>>>
>>> Branches: trunk
>>>
>>> Original Problem:
>>> Since the stdWrap refactoring import.listNum = 0 does not work
>>> anymore and all other functions where = 0 is not meant to be false
>>> will fail, too. This is due to a wrong check in function stdWrap,
>>> line 4461. If changed from
>>> if ($conf[$functionName] || $conf[$functionProperties]) {
>>> to
>>> if (isset($conf[$functionName]) || $conf[$functionProperties]) {
>>> it works again. I did not test possible other effects of that change
>>> at the moment.
>>>
>>> This would have executed boolean stdWrap functions regardless of a
>>> possible value 0.
>>> So required = 0 would behave like required = 1.
>>>
>>> Solution:
>>> The attached patch introduces function types as values of the
>>> $stdWrapOrder array instead of the current "1" and checks these
>>> types before the stdWrap function gets called.
>>> This makes sure that boolean functions will not be executed when
>>> their value is 0, while the rest of the functions will work as
>>> before.
>>>
>>> Additionally it gives us more options to do a kind of "syntax check"
>>>
>>> Will fix #16110 as well
>>
>> Please don't do that. I just noticed this comment after committing
>> 16110 ... and I don't think both bugs should be fixed with one patch,
>> 16110 hasn't necessarily anything to do with this one.
>
> OK. - new v2 will take care of that.
>
>> Question to this patch:
>> - $stdWrapDisabledFunctions =
>> 'cObject,preUserFunc,stdWrap,preCObject,postCObject,prepend,append,postUserFunc,postUserFuncInt';
>> + $stdWrapDisabledFunctions = 'cObject,functionname';
>>
>> You don't disable the same functions as before, or do you? For example
>> prepend and append aren't of type "functionname" and they appeared
>> before, does this have a special reason?
>
> it disables functions based on their type instead of their name, namely those of the type "cObject" or "functionname", so basically it does the same as the list before. But I forgot to add "stdWrap" as well. New v2 takes care of that.
>
> Attached is new v2.
>
> Joey
>

Attached v4 applies cleanly to trunk and adds one naming cleanup: 
$stdWrapDisabledFunctions is now $stdWrapDisabledFunctionTypes

One thing I notice is that the list of function types is mixed case. 
cObject, getText etc are camel-cased whereas functioname, fieldname, etc 
are lower cased. It looks like this follows the conventions from TSRef, 
but transforms function-name to function name. Would it make sense to 
keep be consistent and camel case everything or follow TSRef directly?

Also, would the function types potentially be useful in other places and 
if so would class constants be a better choice rather than strings?

Other than those two comments, +1 on reading with testing to follow 
tomorrow.

Thanks,
Jeff
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tslib_content_v3.diff
URL: <http://lists.typo3.org/pipermail/typo3-team-core/attachments/20101107/26759e72/attachment.asc>