[TYPO3-dev] RFC: Bug #6885 - Nested USER_INT, COA_INT, etc. objects are not rendered

Ernesto Baschny [cron IT] ernst at cron-it.de
Wed Dec 5 11:34:47 CET 2007


Oliver Hader wrote: on 05.12.2007 08:26:

>> Wouldn't it make sense to just make the "last level" USER_INT's and
>> leave the "hierarchy above" USER? After all the "USER" objects in
>> between won't ever be able to "cache" anyway. I agree that this might
>> need more configuration and won't probably work "out of the box" because
>> you have to configure the whole TypoScript tree. But still doable...
> 
> Thanks for your feedback on that issue!
> 
> Do you mean something like this with "last level/hierarchy above"?
> 10 = USER
> 10 {
>   userFunc = tx_cacheext_pi1->main
>   renderObj = COA
>   renderObj {
>     10 = USER
>     20 = USER
>     30 = USER_INT
>   }
> }

Yes, quite. But I meant also to change all "last-level" USER to
"USER_INT", thus:

10 = USER
10 {
  userFunc = tx_cacheext_pi1->main
  renderObj = COA
  renderObj {
    10 = USER_INT
    20 = USER_INT
    30 = USER_INT
  }
}

> The first level is the caching wrapper for the content below. The
> renderObj is a CONTENT object (tt_content) and can be changed in
> backend. Thus, it can also happen, that USER/USER_INT appear there -
> depending on the extensions used.
> 
> See the website here: http://snipr.com/1untz
> 
> 1) left and right columns (at the outer borders) are nearly the same on
> every page of the website

Quite a common requirement!

> 2) if one of the boxes shown there is changed (and is integrated as USER
> in TS), the cache for the whole website has to be cleared (because data
> is written to cache content of each page)

Quite a common way of solving it. :)

> 3) so, the initial first USER_INT in my example could be seen as the
> individual caching layer for the "regular" content below
>
> So, point no. 2 is crux of the matter here and reason for the own
> caching using an USER_INT.

That is true. But consider that when adding a single USER_INT the
performance of every page reduces drastically. I have done some
comparisions, and the overhead of loading the TYPO3-Framework is
enourmous, compared to a "completely cached with no _INT" scenario
(>100ms delivery versus <10ms delivery).

Thus I usually prefer to regenerate every page in cache when some
border-content changes, if this means that all cached pages won't
contain any USER_INT. Of course if you already have a USER_INT somewhere
in your layout for some other reason, this whole thinking is obsolet,
because you are already loading the T3-Framework on each call.

> Okay, then I'm also waiting for comments from others (otherwise we could
> discus this via direct e-mail). :)

I think even if noone else participates.. Maybe someone is just watching
and trying to learn something. :)

Cheers,
Ernesto




More information about the TYPO3-dev mailing list