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

[Ernesto Baschny [cron IT]]

Martin Kutschker wrote: on 23.09.2008 10:10:

>> 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.
> 
> I didn't consider this.

>> 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".
> 
> But how should this be done? There may be many records available but the
> display logic can be arbitrarily complex.
> 
> I cannot think of any reliable way to get to that data. Simply taking
> all records into account is easy but not necessarily correct.

In CONTENT and RECORD it might be "easy", simply execute the same query
we already make twice, once with enableFields and once without
start/endtime filtering. Use the first one for rendering, the second one
for looking up cache expiration. In CONTENT it is a simple exec_getQuery
call, in RECORD it is a loadDB->getFromDB call.

For USER, this has to be done by the userFunc itself. The core must only
provide some helper methods to facilitate that.

AFAI-can-see other cObjects are only used to render a single records
(i.e. they are rendered in the processing of each record of CONTENT or
RECORDS), so irrelevant for cache expiration calculation.

Cache expiration needs to propagate down the cObject hierarchy, so that
the top level cObject (e.g. the "PAGE" object) has information based on
all objects below it (for example a TEMPLATE, which includes a COA,
which might include an USER and a CONTENT, etc).

>> 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).
> 
> Basically a good idea, but I think that hooks or a simple TSFE property
> are more in line with the 4.x architecture.

I can imagine that a OO-based framework could provide very good new
concepts for the already great TypoScript and "cObject" concept, see below.

>> 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?).
> 
> Maybe.

The OO framework (the cObjects returning objects instead of "raw
content") provides many new possibilities (besides the cache expiration
calculation). E.g. a rendered cObject might provide an unique hash (id)
which identifies exactly what has been rendered. The object caching
scheme could use that information to store unique cached objects (not
whole pages, but parts of it!). That would be great for caching for
example "side content": a CONTENT cObject that selects the same
tt_content records to be displayed on a side of every page on a site
(e.g. a news "LATEST" plugin on the right sidebar). The cache should be
so intelligent to notice that it is always the "same" content and only
render it once (which is not possible currently, because we only cache
the page as a whole).

Difficult task, I know, which is why it has been only in my head for
ages, but no time to "do it". :(

Cheers,
Ernesto