[TYPO3-mvc] cache handling and handling of 'no_cache' parameter

[Franz Koch]

Hi list,

I was just do some debugging here and there and wanted to see if extbase 
is doing unnesessary update/insert/delete queries while rendering my 
pages without any changes to the objects. That seemed to not be the 
case, but I found two things that could be improved.

1) The page cache is clear multiple times by extbase in one pageload. 
The author (Jochen or Sebastian) already noticed that the way it's done 
currently is not the best (lines 838/839 from Typo3DbBackend.php):
-----------
// TODO check if we can hand this over to the Dispatcher to clear the 
page only once, this will save around 10% time while inserting and updating
Tx_Extbase_Utility_Cache::clearPageCache($pageIdsToClear);
-----------

I think I can second this inline comment. Having 5 DB generated objects 
(eg. 1 BlogObject and 4 Posts) in use on one page (one plugin instance 
and template), the page cache is getting cleared 5 times in one page 
refresh - so for each object. For more complex sites this will 
definitely slow down rendering.
I tried to work on this and added a method to add pages to the 
"clearPageCache" stack. But I've some issues with the stack being empty 
at the end of the 'dispatch' function of the dispatcher where I'd like 
to finally clear the cache then :( I tried using a classVar as well as a 
static classVar - no luck so far. Maybe I should store it inside some 
register?





2) use of the 'no_cache' parameter for actions that are not allowed to 
be cached (create,edit,etc).

Although this is probably the easiest way to achieve this, it's not the 
best to do. A dynamic switch of the plugin(s) to USER_INT might be a 
good/better idea in this case. To achieve this, I was thinking of a 
TYPO3 condition using a userFunc provided by extBase. This userFunc is 
then checking the current GPvars (which extension keys are in use) and 
is then parsing the extbase configuration of this extension(s) if one of 
the provided actions in not allowed to be cached and is switching it to 
USER_INT then. I know it sounds easier as it might be - but it might be 
worth a try. What are your suggestions about this? Did I miss some 
complex use cases of extensions that might not work or conflict with 
such a solution? Maybe multiple instances allowing/using different 
actions and only those should be USER_INT that allow those actions? How 
could this be achieved?


-- 
kind regards,
Franz Koch