[TYPO3-dev] Fight the no_cache parameter
John Angel
johnange at gmail.com
Mon Apr 16 17:45:00 CEST 2007
> 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.
Of course we need some resources, since we don't have read only content.
> 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.
Yes, something like t3lib_page::getHash() and t3lib_page::storeHash()
Ok, to summarize everything. We have 3 types of caching:
1) 100% caching of the complete ext (ideal for read-only content, like
displaying forum threads) - solution: USER
2) 100% not-caching (don't know what for) - solution: USER_INT
3) Mixed caching (ideal for any kind of form) - solution: USER with
set_no_cache() or pure USER_INT - both bad
I am trying to find solution for mixed caching - to avoid set_no_cache().
My idea was: to use USER_INT. It will be postprocessed and our ext will
decide what to do - to display cached content or not cached.
E.g. there will be a method in the class:
function whether_to_cache()
{
return (is_there_search_query) ? FALSE : TRUE;
}
Parent class (USER_INT) will decide how to handle caching, depending on this
value. E.g.
if($this->whether_to_cache())
{
if($cache=t3lib_page::getHash(...))
{
return $cache;
}
else
{
$cache=$this->main(...);
t3lib_page::storeHash($cache...);
return $cache;
}
}
else
{
return $this->main(...)
}
I've also proposed extending storeHash() to provide better functionality for
caching on extension level:
http://bugs.typo3.org/view.php?id=5425
Regards,
John
More information about the TYPO3-dev
mailing list