[TYPO3-project-4-3] idea: styles.content.getMulti

Ernesto Baschny [cron IT] ernst at cron-it.de
Mon Aug 24 16:10:09 CEST 2009


Martin Kutschker schrieb:
> Steffen Ritter schrieb:
>> Martin Kutschker schrieb:
>>> Hi!
>>>
>>> TYPO3 needs a SELECT for each column and for each language. How about
>>> fetching all records of the current page in the wanted column positions
>>> (maybe you need only two of four possible) and in all required languages
>>> (that would be the default language, the current language and all
>>> fallback languages).
>>>
>>> A tweaked CONTENT CE could then use this data instead of doing many
>>> queries.
>>>
>>> Note: sliding content and WS preview will make this more complicated
>>> then it may look at a first glance!
>>>
>>> Masi
>> Don't get how may spread the Content to different places?
>>
>> Like, first get all, afterwards using content it uses cached data which
>> i can say: render only with col=1?
>>
>> Would be a charme if you may give an example.
> 
> Something like that:
> 
> # load records to memory but don't render anything
> page.10 < styles.content.getMulti
> # show lang. 3 with a fallback to 6
> page.10.languages = 3,6
> # show cols 0,1 and 2
> page.10.columns = 0,1,2
> 
> page.20 = CONTENT_MEM
> page.20.column = 0
> 
> Maybe a standard register instead of the "memory" could be used to store
> the records temporarily.

That sound nice, but I would prefer to have this "caching" and
"restoring" something that TYPO3 does in "background" and the
FE-developer doesn't need to bother with.

Why don't we keep the current getBorder etc, maybe adding a "speed-up"
method so that the "first one" just fetch all necessary records (in one
query) and other future getXXX can make reuse of them? After all it is
just a filtered "select" query, we can also do the most used "filtering"
in PHP if we have all records in memory.

This would make this feature more intuitive for users to use.

Cheers,
Ernesto


More information about the TYPO3-project-4-3 mailing list