[TYPO3-project-4-3] 4.3.0 vs. 4.2.7

Martin Kutschker masi-no at spam-typo3.org
Fri Jun 12 16:53:36 CEST 2009


JoH asenau schrieb:
> 
> Taking a look at the "content" that is generated by CF:
> Simple Login Form => http://t3designkit.4any1.de/index.php?id=2
> Even simpler "Hello World" => http://t3designkit.4any1.de/index.php?id=5

That's the same stuff as always. The CF simply stores the submitted data
somewhere. But I always wondered, but never investigated, how TYPO3
exactly caches content and why it needs tables with names like
"cache_pagesection".

> And another question:
> Does it really make sense to use a constructor that has to "build" the
> backend and frontend used by the CF on each request again and again?
> Why can't we just use ready made files for each possible combination of
> cache frontend and backend, which then will be triggered by a simple
> matching combination in TYPO3_CONF_VARS instead of such a "framework"?

I'm not familar enough with the CF to get what you mean. Could you
explain or give a short example?

> After all caching (framework or not) is about performance and not about
> implementing fancy programming patterns.

Hah! :)

> Why does the CF use exec_SELECTgetRows for the "db backend", if there will
> be just one entry per identifier anyway?
> What about checking for MySQL COUNT being TRUE instead of fetching a whole
> dataset and counting it's entries with PHP to check for the existence of an
> entry?
> What about _always_ using SQL functions _during_ the query instead of PHP
> functions on arrays _afterwards_?

This is implementation detail. AFAIK the approach of the v5 team was to
get things running first and do the tuning later. Feel free to provide
patches that speed-up the DB backend.

Masi


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