[TYPO3-dev] set_no_cache is bad. What's next?

[Martin Kutschker]

Steffen Kamper schrieb:
> "Martin Kutschker" <martin.kutschker-n0spam at no5pam-blackbox.net> schrieb im 
> Newsbeitrag 
> news:mailman.1.1175457783.11183.typo3-dev at lists.netfielders.de...
>> Steffen Kamper schrieb:
>>> "Martin Kutschker" <martin.kutschker-n0spam at no5pam-blackbox.net> schrieb 
>>> im Newsbeitrag 
>>> news:mailman.1.1175358350.7942.typo3-dev at lists.netfielders.de...
>>>> Michael Stucki schrieb:
>>>>>> When I suggested improvements to the responsible persons the answer 
>>>>>> was
>>>>>> meaningful silence instead of taking up my thoughts and find out how 
>>>>>> it
>>>>>> could be done. I am tired now of this way. It was practically 
>>>>>> impossible
>>>>>> to get tslib_pibase improved. So the only consequence it to replace 
>>>>>> it.
>>>>>> Masi is fully right in this.
>>>>> We're once again at the subject of compatibility. I agree completely 
>>>>> that
>>>>> tslib_pibase should be replaced with something better, and apparently 
>>>>> you
>>>>> are already doing that.
>>>> With replacement I mean something new alongside of tslib_pibase. 
>>>> Removing it from the Core is of course no option. Simply add the hot new 
>>>> stuff into tslib and make the Kickstarter support it.
>>>>
>>>> Masi
>>> what do you think about making a new function in pi_base, like
>>>
>>> function 
>>> pi_makeLink($str,$urlParameters=array(),$cache=0,$additionalConf=array(),$altPageId=0) 
>>> {...}
>>> function 
>>> pi_makeLink_url($urlParameters=array(),$cache=0,$additionalConf=array(),$altPageId=0) 
>>> {...}
>>>
>>> so we have 1(2) new functions as typolink-Wrapper, keep a simple handling 
>>> and be compatible to old versions.
>>> $additionalConf would be overriding conf for typolink.
>> And have two more to add to the mess.
>>
>> Masi
> 
> Hi Masi,
> 
> the idea is to leave the mess. It's only a possible example - if we have one 
> simple function that don't use the settings of the plugin setting, we can 
> add this functions to the kickstarter and educate the developers to use the 
> new functions in a good manner. After a while the older functions get 
> obsolete. The change of coarse is a long time process.
> Also this would be a way to change this more quick. If you have a better 
> idea how we can solve this, please let us know.

I have repeatedly stated my idea: Let pibase stay in tslib, but create a 
new class. The Kickstarter will create code for the new class.

This is clean and means the Core is backwards compatible.

Having multiple APIs in one class is a really horrible idea.

Masi