[TYPO3-dev] Fight the no_cache parameter

[Elmar Hinz]

Am Mon, 16 Apr 2007 16:35:56 +0200 schrieb John Angel:

> 
> Exactly, that's why I am talking about that the ext has to be USER_INT. So
> when rendering page, Typo3 calls ext every time and ext decides whether to
> display cached content (search form) or not cached (search results).

A cached page isn't rendered every time, but each cached page is
"postprocessed" to execute USER_INT. 

Bottomline: USER_INT in cached USER work. caching USER in USER_INT
don't work. 

Am I right that your idea is this: You can apply a non-USER-based caching
mechanism during USER_INT postprocessing. That should work, but has some
drawbacks:

 1.) For each cached plugin you shortly need to execute a USER_INT only to
 draw the content from a different cache then. That needs at least some
 resources.

 2.) As you don't use standard caching of the whole page, you would need
 to apply additional techniques to get your cached content into the search
 index.

Because of this reasons I think your proposal is specially usefull for
plugins that need a timely limited caching. For unlimited cached plugins I
would still prefer a traditional USER. 

> 
> So the ext is USER_INT, and somehow from PHP it should decide "cache my
> content" or "don't cache my content".

Regards

Elmar


-- 
Fight the no_cache parameter:
http://t3flyers.wordpress.com/2007/04/06/a-quick-guide-to-proper-caching-with-tslib_pibase-episode-1/
http://t3flyers.wordpress.com/2007/04/06/a-quick-guide-to-proper-caching-with-tslib_pibase-episode-2/