[TYPO3-ect] tx_base - tslib_pibase modernized

[Michael Stucki]

Hi Elmar,

>> Let's say this: Usually a cached object is a USER object and has
>> $this->pi_checkCHash set to TRUE, while for non-cached objects (USER_INT)
>> it is the opposite. I'm aware that it's currently possible to do this
>> differently, but practically I see no sense in it. For me it seems ok to
>> require that cached objects require cHashes all the time.
>> 
>> So maybe we could just set $this->pi_checkCHash and
>> $this->pi_USER_INT_obj automatically, like this:
> 
> I already have thought about this solution, but I fear it isn't that
> easy.

I don't think so, but let's see:

> Imagine a typical search from (USER_INT) with a result browser
> (unlimited combinations of parameters). In the border there are a few
> little, nice static plugins (USER). In this case the USER plugins
> don't depend on parameters. (In fact they couldn't because we need a
> flexible URL for the result browser.)
> 
> In your suggestion each of this USER plugins would trigger checkCHash, if
> I understand it right.

Yes

> The USER plugins in the borders have themself no parameters to receive,
> but they would influence the USER_INT in the same way as if we would
> always activate checkCHash. Right? So we would run into the same problems
> with pageNotFoundOnCHashError = 1. 

No. The USER_INT cObj will still have checkCHash disabled. I don't see a
problem here.

>>> Maybe it's a kind of conceptional bug in the core. The current fix
>>> of this bug is to ser pageNotFoundOnCHashErr=0. Wouldn't it be possible
>>> to alter the pageNotFoundOnCHashError behaviour by an additional
>>> condition:
>>> 
>>> *******************************************************************
>>> Only check the cHash if a cHash has been given.
>>> *******************************************************************
>>> 
>>> That would IMHO solve the problem.
>> 
>> This would work with USER_INT objects, but still I dislike the solution
>> because this way you can just remove the cHash from a URL and send
>> whatever you want to that page. I would rather like to enforce the cHash
>> to me it is
> 
> Isn't that exacly what you typically do with USER_INT? I don't see the
> problem here.

Currently, yes. I was thinking of a future scenario when cHash is used as a
parameter check. For the moment, your proposal above makes sense.

>> not only a "cacheHash" but also a "checkHash". One day I would like to
>> use it for solving the "&no_cache=1" problem...
> 
> That is exactly my theses. Check&Cache whenever a valid cHash is send. The
> control should happen in the moment the cHash is created. Quite simple.

There might be problems when you mix USER and USER_INT objects on one page.
Oliver Hader already had some thoughts about this, see
http://bugs.typo3.org/view.php?id=5010. However, this is a future step and
has nothing to do with the caching issues...

- michael
-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/