[TYPO3-mvc] Concept of dynamic USER_INT switch maybe has to be refactored?

Franz Koch typo3.RemoveForMessage at elements-net.de
Tue Mar 2 13:20:52 CET 2010


Hi Steffen,

> if the dispatcher is userobject, and is cached it would not get called
> anymore so that it may trigger i think.

sure, but that's not a problem. If the default controller/action pair is 
allowed to be cached, it shall be cached. But if you now click on a link 
from your extension, you're most likely submitting some parameters in 
the URL and the page will get rendered again (of course only with a 
valid cHash appended). In the new rendering process the decision for 
USER or USER_INT can be done again. So that's in fact no problem at all.

The only situation where it could become a problem is when you have a 
extension that should be cached in the default view but should be 
USER_INT as soon as any parameter is submitted, but withouth any cHash. 
But that's a general problem with any extension in TYPO3 and nothing we 
can handle without manipulations on TYPO3s caching mechanism. So in 
those cases some custom TS conditions are needed or the extension has to 
be USER_INT by default, just like for any "traditional" extension.

-- 
kind regards,
Franz Koch


More information about the TYPO3-project-typo3v4mvc mailing list