[TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions

Martin Kutschker masi-no at spam-typo3.org
Thu Sep 18 09:44:59 CEST 2008


Ingo Renner schrieb:
> Steffen Kamper wrote:
> 
> Hi Masi,
> 
>>> But it relies on the database for implementation. Do we really need such
>>> a heavyweight code? DB down => auto loader breaks? Doesn't sound too
>>> compelling to me.
> 
> Well what's the difference to now? DB down => TYPO3 down, right?

DB down => error message shown. But what if the display of the error
message would require a class to be found via auto loader?

> Of course it could be an option to have all class->file relations stored
> in a huge array and then have that stored serialized. This however would
>  slow down the system because of the huge array. I rather find it better
> to look only the requested classes/files.

That's why I simply would go for a class name to file path translation.
So we don't need no array or DB at all for single classes. We need only
an array for class prefixes. t3lib_ => PATH_t3lib.'class.'... etc

And we don't even need that if we use SPL. t3lib and tslib would simply
have their own SPL autoload handler. With typo3 you need a bit more
fiddling, but if we rearranged the code filename-wise (yes it would only
be 99% compatible) even that is easy to manage.

> I don't know whether you noticed this fine bit, but they store which
> classes/files were needed for a certain URL path/menu entry. We could do
> this too when binding it to the cHash or the pageId, right? This would
> totally justify the use of a DB, wouldn't it? You could look up all the
> files needed for a page with a single query.
> 
> does that sound good?

I don't see much benefit. The code called to render would still do a
"require". Of course it will be loaded by then already, but I don't see
how this will improve speed.

Masi


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