[TYPO3-ect] tx_base - tslib_pibase modernized

[Ernesto Baschny [cron IT]]

Elmar Hinz wrote: on 03.04.2007 01:22:

>>> 2.) $pi_checkCHash should be set to TRUE by default (I see it's not
>>> implemented yet.) So in doubt caching works simply by selecting USER.
>> But won't this break a plugin specifically set to "USER_INT"? I think
> 
> It would not break. USER_INT is dynamic. It is not interested in the
> question if there is a cHash or not.

I mean the extension might not care about it, but if you set
"pi_checkCHash" to TRUE it is TYPO3 who will check if the cHash is
correct. As soon as you set the pageNotFoundOnCHashError to 1 and your
USER_INT starts using piVars in _GET, you will get TYPO3 errors
("Request parameters could not be validated").

So the correct would be to not generate a cHash if the target is a
USER_INT which can be parametized through piVars and do NOT set
pi_checkCHash in your USER_INT plugin, as you don't need TYPO3 to check
on cHash in that case!

In case of USER and wanting cHash checked, simply call:

   if (count($this->piVars)) {
      $GLOBALS['TSFE']->reqCHash();
   }

> You can checkout the extension cherries from SVN to test out details.

Just did, and the above error rised on the USER_INT and the link
"Parameter with designator but without cHash", as expected when
pageNotFoundOnCHashError is set to 1.

>> My idea would be to have as little caching as possible (USER_INT by
>> default) so that the beginner will see results without having to
>> set_no_cache(). But then provide some "easy" ways to turn the script to
>> a USER script. Or maybe have more information in the kickstarter near to
>>  checkbox where the user chooses "USER" or "USER_INT"?
> 
> Right. The user decides in the kickstarter himself. So there is no
> default. But it is very important to tell him where he can switch between
> USER and USER_INT.

That is true, because after kickstarter generates it, most people don't
know and it is very well hidden as a boolean parameter to addPItoST43.

> You forget that there are links to internal and external targets. Also
> Kasper obviously has forgotten this, when he invented pi_USER_INT_obj.
> 
> http://t3flyers.wordpress.com/2006/09/11/a-quick-guide-to-correct-caching-with-pi_base/
> 
> With idea of pi_USER_INT_obj you barking up the wrong tree. You can't do
> the switch globally. You need to do decide for each link again.

That is correct. I thought the "beginners" level you were aiming we
would either have a "cache all" (USER) or "cache none" (USER_INT)
scenario, so this would be a candidate for a default.

So as far as I read your URL above, you propose that a beginner starts
with a USER / USER_INT switch already. So kickstarter should generate
that switch?

> Simply use: isDestinationCached.
> 
> a) If you set it to true with a USER_INT: no problem but not pretty.
> b) If you set it to true with a USER: fine.
> c) If you set it to false with a USER_INT: fine.
> d) If you set it to false with a USER: It falls back to the default cache.
> 
> Checkout cherries.
>
> As you see d) is the only case that causes troubles. You would always get
> the same output from the page. You would quickly set isDestinationCached
> to true.

Or call "set_no_cache()" which is what is currently happening when a
developer stumbles over that problem. :)

So having that sorted out (we agree on that matter of pi_USER_INT_obj
being ugly), the only "trouble" that remains is how to make a beginner
understand the separation of plugins (USER / USER_INT) for "simple"
tasks like list and detail views? Should kickstarter generate some sort
of switch in TypoScript? Or should the core do it (in methods like
addPlugin or addPItoST43-renamed)?

Cheers,
Ernesto