[TYPO3-mvc] Caching problem?

[Franz Koch]

Hey,

>> If I got you right, it's currently not necessarily a Extbase bug
>> (although Extbase might use the USER_INT switch a bit uncommon), but
>> merely a wrong plugin configuration by the developer, because with
>> Extbase you of course can also split up cached/noncached actions in
>> separate plugins like in the pi world.
>
> It is a wrong implementation in the Extbase that comes from a
> misunderstanding of how cHash works.

We know how cHashes work and are ought to be used - but your are right, 
we were not aware of the fact that the switch should only be used 
plugin/instance wise and not view(piBase) or action(Extbase) wise and 
haven't thought of all possible side effects.

I totally agree that mixing cached and non-cached actions might not be a 
concept that's meant to be used in the v4 world, but it's a legitimate 
demand which we try to meat with Extbase. That it's needed show many 
pi-based extensions happily triggering &no_cache=1 to achieve this as 
well as some topics on this list. And AFAIK it'll be possible for 
v5/FLOW3 we try to be as much compatible as possible.


> Since Extbase supports having
> cached and non-cached actions in the same plugin, it should correctly
> switch between them and produce proper links, that's all.

we create "proper" links according to the intended type of the target 
action, but that's the issue in mixed setups. They don't work if the 
first action is cacheable. So the question is, do you suggest to either 
switch the whole plugin instance to USER_INT as soon as one action is 
non-cacheable (so use the switch as it's used to be), or always append a 
cHash and flood the page cache. In my eyes neither is acceptable, that's 
why I'm still looking for alternatives to get this demand into Extbase 
in a clean an proper way.


> Well, I do not think we need cHash in TYPO3 at all. It is perfectly
> possible to implement content caching without passing it here and there.

The cHash is a easy way for the framework to detect if submitted 
parameters are valid and can be cached without having to ask the 
according plugin, so I think having it is not a too bad concept 
performance wise, but there for sure might be better solutions.

-- 
kind regards,
Franz Koch