[TYPO3-core] RFC #9284: Feature: tt_content.starttime/endtime have now effect on caching

Ernesto Baschny [cron IT] ernst at cron-it.de
Tue Sep 23 09:54:05 CEST 2008


Martin Kutschker wrote: on 22.09.2008 22:46:
> Martin Holtz schrieb:
>>> I would love to have a generic way the rendering process could gather
>>> caching expiration information at run-time while it is being generated.
>> me too:)
>>
>>> In general this is a very very complex area and probably a generic and
>>> "works-for-all" solution isn't possible at all.
>> that is what i think - or, an "works-for-all" solution will have too much
>> overhead. The additional select-Query is only used, if we write the page to
>> cache. 
> 
> If you collect the info in RECORDS and CONTENT you need no extra query
> at all. Plus you don't get "bogus" inormation from records not rendered
> at all.

Complicated is the fact that you need to collect info from records not 
rendered at all, for example for those which start-time in future. So 
the CONTENT query will already filter those out at SQL-time, but you 
need to look at them too, if you want to calculate the "earliest cache 
expiration time".

> All other stuff can - and must  be handled by extensions via a hook that
> modifies the page caching time

Extensions (plugins) are also cObjects ("USER"). I thought about 
changing the API of all cObject methods (PAGE, USER, COA, etc) so that 
they return not simply their html-content, but an "object" (to be 
PHP5-OO-conform) which contains not only the content, but also the 
earliest expiration date of the generated content. So that the calling 
object can use that information when calculating his own earliest 
expiration date (as the objects might be nested).

I think this also would come in line with the planned project "content 
object caching", which as far as I know has been planned for TYPO3 4.3 
(Stucki, Oli?).

Cheers,
Ernesto


More information about the TYPO3-team-core mailing list