[TYPO3-dev] Data exchange between USER/USER_INT

[Ernesto Baschny [cron IT]]

Oliver Hader wrote: on 04.12.2007 12:00:

>>> I have a TypoScript situation like this:
>>>
>>> 10 = COA
>>> 10 {
>>>   10 = USER_INT
>>>   10.userFunc = tx_myext_pi1->main
>>>   20 = USER
>>>   20.userFunc = tx_myext_pi2->main
>>> }
>>>
>>> The USER part (pi2) is rendering something and generates also some
>>> information that is required by pi1, the USER_INT object. If the page
>>> was cached once, the USER object isn't processed anymore and thus the
>>> USER_INT doesn't have the required additional information.
>>>
>>> Currently the USER object is putting it's information to the TSFE:
>>> $GLOBALS['TSFE']->config['extensionStorage']['tx_myext']['whatever'] = 1
>>>
>>> The $TSFE->config array is cached in the table 'cache_pages' by default
>>> and thus, the USER_INT object has the required information automatically
>>> on the next hit to that page.
>>>
>>> But my question to you is: What would you use in this case? What is your
>>> best-practise?
>> That would be a new way I have never thought about. :) But to me using
>> the "config" array seems a bit of a "misuse" for this purpose.
> 
> Well, maybe... ;) But there are other things stored in $TSFE->config
> (besides the CONFIG TypoScript in $TSFE->config['config']), like
> 'rootLine', 'FEData' and 'INTincScript'.
> What I called 'extensionStorage' should normally be part of an entry in
> the 'INTincScript' array which is for the same purpose.
> 
>> I would let USER store the information in cache_hash (see other post
>> about the API). The problem here is the same as in your approach, the
>> cached information will only be "refreshed" once the USER object is
>> recreated. But if this is desired (e.g. not dependent on user session or
>> page where the plugin is being called from), you could use any cache you
>> like.
> 
> This is one of the multi-optional problems of TYPO3. It's possible to do
> it in different ways, but the developer has to decide one. I'd like to
> have a general 'extension storage' that can handle data created by
> runtime and put it into cache. This function also has to be loaded and
> written automatically (like it's done in the $TSFE->config example),
> because otherwise each extension which requires this behaviour has to do
> its own caching again and again.
> 
> What I try to explain is: We need some standards for such things.

I don't see that you are creating a standard, but just one more way to
cache data in TYPO3. And having a standard where extensions store more
and more stuff in TSFE which has to be loaded on each call doesn't look
like something that would scale to me.

storeHash and getHash are already there and you can use it. It might not
be the most well documented feature, and maybe there are missing
features with it (e.g. a too short "ident" field or no
"memory-caching"), so we might enhance it. But it works well and I have
used it for caching FE-rendering stuff in several applications.

Your use-case is also very particular (passing information from USER to
USER_INT) because of the problem that the USER won't be called again
until the page-cache is cleared. This is probably why you prefer to use
TSFE for storing. But I think this use-case is very rare. You might as
well refactor the "creation" of the cached data in such a generic way
that the USER and the USER_INT might use it, whoever needs it. This kind
of "cross dependency" can be dangerous.

Cheers,
Ernesto