[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