[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