[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