[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