[TYPO3-core] RFC #8985: Enable USER object to become USER_INT on the fly

[Steffen Kamper]

Ralf Hettinger schrieb:
> Hi,
> 
> what I don't understand is why this is necessary to solve by applying 
> core changes.
> 
> 
> You could already do this by having some code in your main function of 
> an FE plugin - with even less code (an example follows).
> 
> I'm afraind I'm missing the point... would be glad to hear, what the 
> extra benefit of this feature request and patch is.
> 
> Thanks
> Ralf
> 
> 
> 
> Example:
> Let's assume some ext with extension's name 'dummyext' and main function 
> 'main($content,$conf)' ... then you could do this by
> 
> 
> main($content,$conf) {
> 
> [...]
> 
> // make it a USER_INT, if some conditions are met.
> // assumptions:
> // 1) $this->conf['__USER_INT__'] is not used as configuration
> //    and therefore just false by default.
> // 2) $needToBecomeUserInt is some condition, that was set to
> //    true before by the script logic, if USER should become USER_INT
> if (
>   $needToBecomeUserInt &&
>   !$this->conf['__USER_INT__']
> ) {
> 
>   // $this->conf might have been merged with flexform config before
>   $user_int_TS_conf = $this->conf;
> 
>   // for the next run, we will have a USER_INT -
>   // so don't descend into this if-switch again:
>   $user_int_TS_conf['__USER_INT__'] = true;
> 
>   // initialize includes and functions for the next run
>   $user_int_TS_conf['includeLibs'] = 
> $GLOBALS['TYPO3_LOADED_EXT']['dummyext']['siteRelPath'].'pi/class.tx_dummyext.php'; 
> 
>   $user_int_TS_conf['userFunc'] = 'dummyext->main';
> 
>   // return a USER_INT instead of the plugins' content.
>   // will result in one more run of the main function
>   // - this time outputted as USER_INT
>   return $this->cObj->cObjGetSingle(
>     'USER_INT',
>     $user_int_TS_conf
>   );
> }
> 
> 
> 
> 
> 
> Dmitry Dulepov [typo3] schrieb:
>> Hi!
>>
>> This is SVN patch request.
>>
>> Type: feature
>>
>> Branches: trunk
>>
>> BT reference: http://bugs.typo3.org/view.php?id=8985
>>
>> Problem: some extension (for example, tt_news) have an option to 
>> disallow caching. At the moment they simply call $TSFE->set_no_cache() 
>> disabling cache for the whole page. This has huge performance impact 
>> (as we all know). Just imagine such plugin on every page of web site 
>> ("latest news"). TYPO3 so far did not provide any way for plugins to 
>> make them non-cachable on the fly. Objects can be set to USER_INT 
>> through TS but object itself will not have any idea in what mode it 
>> runs (this is important sometimes).
>>
>> Solution: allow to switch from USER to USER_INT on the fly. Add two 
>> new methods and two public constants to tslib_cObj for this. Here is 
>> how easy extension can convert itself to USER_INT after applying this 
>> patch to core:
>> ==========================
>> if ($this->cObj->getUserObjType() == tslib_cObj::OT_USER) {
>>    $content = 'I am running as USER object now.';
>>    if (!$this->conf['allowCaching']) {
>>        $this->cObj->convertToUSER_INT();
>>        return '';
>>    }
>> }
>> else {
>>    $content .= 'I am running as USER_INT right now';
>> }
>> ==========================
>> The only requirements for extension are:
>> - check what mode they use right now (USER or USER_INT) before proceed 
>> with further work
>> - have "includeLibs" in TS setup (it is required for any USER_INT object)
>>
>> Next objects can be declared as USER and run normally. If admin sets 
>> allowCaching to 0 in TS, TYPO3 will clear cache and USER object will 
>> know it has to convert itself to USER_INT.
>>
>> The solution was cooking for some time and I think it is good. I also 
>> attach test extension here. It should be inserted on page and its TS 
>> added to main TS setup. Next you can experiment with plugin on the 
>> page. It will tell you what to do ;) It will show you current mode and 
>> proof that it runs as USER or USER_INT.
>>
>> getUserObjType() returns OT_USER or OT_USER_INT if called from the 
>> USER or USER_INT object. Otherwise it will return false.
>>
>> Possible question: how does it affect per-object caching idea? In no 
>> way. This is different from per object caching.
>>
>> Before this patch gets in, I'd like at least two +1s by *testing*. +1s 
>> by reading is not enough because the feature is complex (relates to 
>> caching).
>>

the same old story. Joey posted this technique, i made a tutorial of it, 
and it was discussed many times. i proposed a wrapper for simple usage.
This was discussed several times without any result (without that many 
devs know how to do it)

As long as the cache is a "mystery" we will have a lot of issues 
concerning to this.

vg Steffen