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

[Marcus Schwemer]

Hi,

+1 by reading and testing.

Kind regards,
Marcus

Jeff Segars schrieb am 08.11.10 05:31:
> 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