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

[Steffen Kamper]

"R. van Twisk" <typo3 at rvt.dds.nl> schrieb im Newsbeitrag 
news:mailman.102850.1175183278.21067.typo3-dev at lists.netfielders.de...
> Dmitry Dulepov wrote:
>> Hi!
>>
>>  From time to time I see that people try to use $TSFE->set_no_cache() in 
>> extensions. You know what happens next: no caching for pages, performance 
>> is terrible, web server is not responding, etc. At the same time, 
>> sometimes, in really rare cases caching must be disabled. But definitely 
>> not this way from extensions.
>>
>> Should we change this function in some way? Should it explain people that 
>> using it is no-good?
>>
>> Personally I would vote for radical methods like (1) keeping it but 
>> emptying or (2) writing commented phrase inside generated FE page that 
>> set_no_cache was used, so do not expect good performance.
>>
>> Any other ideas/opinions?
>>
>>
> Hey Dmitry,
>
> when I started with typo3... I also fell into that function.
> set_no_cache() for me (back then) did mean no caching for
> the current extension, instead of no caching for the entire page.
> The function name wasn't clear enough, and I didn't knew (back then)
> were to find the correct documentation for it..
>
> What we can do is slowly depreciate the function creating, however
> we need to notify the user, and in some way the extension owner.
>
> These two options spring into my mind.
>
> 1) We setup some rules on TER that can search for these functions.
> And send the maintainer a mail about that a function is going to get 
> depreciated.
>
> 2) We can setup typo3 in debug mode. And every time a depreciated function 
> is
> going to get called we show that on the screen.
>
> something like:
>
> DEBUG: set_no_cache(); is going to get removed in 4.5
>
>
>
> By depreciating functions we can make sure that we keep on growing
> typo3 and at the same time remove our 'mistakes' from the libraries.
>
> The bad thing is that it might get more hard to update a typo3 
> installation
> because of the use of old extensions with new versions of typo3.
>
>
>
> However, I do feel that something needs to be done and by notifying people
> on time (like 6 months or more ahead) we can keep on using the current 
> codebase
> effectively.
>
> It also makes sure that extensions are going to get depreciated or getting 
> updated.
> But not left alone right now.
>
>
> RIes
>
>
>
>

Hi Dmitry, Ries, and all

same happens with no_cache=1 in Forms, but first way is worst,

The reason is, that cache-handling is not easy to understand, and developers 
running in problems with cache. i remember my first extensions, i had same 
problems, POST-Vars disappeared, and only way i knew was disabling cache.
Now, you see in discussions in ECT, its difficult too if you need both ways 
in extension, cached and non cached. The pi_base doesn't handle it in strict 
way, Extensions are USER or USER_INT etc.Doin' the wrong combination, it 
floods the chash-table.

The only way i see is to give the developers easy using and understanding 
functions to handle cache in extensions, set_no_cache() could be disabled 
(but this isn't backward compatible)
May be a team has to test extensions that make use of this and contact the 
author, that the extension will be removed if they don't change that. But 
who will do this ?

Anyway it's a good idea to think about that, disablin cache prevent indexing 
and slows down the TYPO3-Site.

vg  Steffen

>
>
>
>
>
> -- 
> Ries van Twisk
> Freelance Typo3 Developer
> === Private:
> email: ries at vantwisk.nl
> web:   http://www.rvantwisk.nl/freelance-typo3.html
> skype: callto://r.vantwisk
>
>