[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