[TYPO3-dev] Data exchange between USER/USER_INT

Oliver Hader oh at inpublica.de
Tue Dec 4 20:23:00 CET 2007


Hi Ernesto,

Ernesto Baschny [cron IT] schrieb:
> 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.

The intitial example was thought be just an _example_, nothing more. And
all I wanted to know was if there was a better way to do this. Putting
(maybe large) things to TSFE doesn't make sense, of course. Furthermore
I didn't say that I'm creating a standard - but it would be nice to have
some standards for common tasks (besides my special use case). And since
caching is sometimes a mystical thing, I would be great to have also
some kind of standard API for extension caching.

> 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.

Great! Then I'm asking you to update and enhance the documentations on
that and feed it with your knowledge concerning this topic. Thanks in
advance! :)

olly
-- 
Oliver Hader
http://inpublica.de/




More information about the TYPO3-dev mailing list