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

[Franz Holzinger]

Dmitry Dulepov a écrit :
> Franz Holzinger wrote:
>> Yes, but if you have a part which changes after the USER has already
>> been generated, then you cannot call the generation of the USER_INT
>> again. Normally the page should be cached.
> 
> Correct. But my feature was only for the case I described, not for the case you describe :)
> 
>> But Masi has written, that in TYPO3 there will be internally a marker
>> for each USER_INT object. Then the PHP code for the USER_INT should be
>> called each time again, even it is embedded in a PHP code by a cached
>> USER object. The USER php code will not be called again, but the final
>> output will still be generated dynamically, when the internal markers of
>> all USER_INTs get replaced by their latest dynamic contents.
> 
> It still has consequences. Firsts, TYPO3 will have to decode that marker, then load all necessary files and finally execute it. Not the fasted way. In addition you loose cache headers.
> 
> You can do better with conditions. Some of my extensions use it. If the form is submitted, TS condition makes USER_INT instead of USER. 
 > always use "typo3_user_int" as a form field that I check in conditions.

But normally the biggest part is never changed and could be a USER 
object. This is e.g. the single view of a product. Then there is only a 
small dynamic part which changes frequently and cannot be cached: e.g. 
the current amount of items in the basket for this FE user.
If I switch the whole output into a USER_INT, then nothing would be 
cached at all. So a USER_INT could be a drawback in the case of a big 
HTML part which will never change. A USER_INT is always much slower than 
a USER object.


- Franz