[TYPO3-dev] Is $this->pi_USER_INT_obj a conceptional mistake

[Elmar Hinz]

Dmitry Dulepov wrote:
> 
> There can be extensions relying on those two. At least many of
> extensions set the second, if it is removed, many extensions will be
> broken at the same moment. -1.
> 

Hi Dmitry,

Why should they break if they use the second?  If they set the
$this->pi_USER_INT_obj, they supress the $no_cache parameter by this. If
you remove both you have the same effect: no $no_cache parameter. So where
is the problem here?

Let's look at the differen cases in detail:


==========================================
cHash:
==========================================

Case A:

Before: $cache = 0  AND  $this->pi_USER_INT_obj = 0   => no cHash
After:  $cache = 0                                    => no cHash

Case B:

Before: $cache = 0  AND  $this->pi_USER_INT_obj = 1   => no cHash
After:  $cache = 0                                    => no cHash

Case C:

Before: $cache = 1  AND  $this->pi_USER_INT_obj = 0   => has cHash
After:  $cache = 1                                    => has cHash

Case D:

Before: $cache = 1  AND  $this->pi_USER_INT_obj = 1   => no cHash
After:  $cache = 1                                    => has cHash

Do we need to discuss this case? It's a ambiguous, nonse configuration. So
it should be very rare. If there is such an absurde setting at all, a cHash
to much can't do much harm.


==========================================
$no_cache:
==========================================

Case A:

Before: $cache = 0  AND  no $this->pi_USER_INT_obj    => $no_cache = 1
After:  $cache = 0                                    => void


This is the case to discuss.

A lot of monolithic extensions are of the type USER and still use the
$no_cache setting for the dynamic parts like search forms. I fear this is
the way the kickstarter still teaches it today. This are performance killers.

If we remove the $no_cache from the pi_base link functions this extensions
break until they are fixed. That would be a desired effect. They have two
options to react:

1.) Simply switch them to USER_INT, gain performance, loose indexing.
2.) Split them into a USER and a USER_INT part, what would be best practice.


Case B:

Before: $cache = 0  AND  $this->pi_USER_INT_obj = 1   => void
After:  $cache = 0                                    => void


Case C:

Before: $cache = 1  AND  no $this->pi_USER_INT_obj    => void
After:  $cache = 1                                    => void

Case D:

Before: $cache = 1  AND  $this->pi_USER_INT_obj = 1   => void
After:  $cache = 1                                    => void




Regards

Elmar