[TYPO3-core] Feature #9633: Implement autoloading for TYPO3

[Sebastian KurfŸürst]

This is an SVN patch request.

Type: Feature

BT Reference: http://bugs.typo3.org/view.php?id=9633

Branch: trunk

Problem:
Currently, lots of files get included at each request, without being 
needed at all (Example: Caching framework). To get rid of this problem, 
we're introducing the new autoloader here.

Solution:
The autoloader has to deal with quite a lot of different situations:
- core files (tslib, t3lib, but also core files not having these naming 
conventions)
- classical extensions (tx_myextension_piX, ...)
- new extensions with FLOW3 naming conventions, f.e. all Extbase based 
extensions
The FLOW3 naming convention is the easiest to implement, because it has 
very detailed rules where a file implementing a certain class must 
reside in the filesystem. Unfortunately, no such strict rules exist 
inside TYPO3 core and classical extensions (example: t3lib_Singleton 
resides in t3lib/interfaces/class.t3lib_singleton.php).

Thus, the autoloader is divided into two parts:
1) If the class which should be loaded starts with Tx_ (the backported 
naming convention from FLOW3), we can use a very simple autoloader 
because of the rigid conventions (implemented in 
t3lib_autoloader::getClassPathByDirectoryStructure).

2) For classical extensions and the TYPO3 core, we use the "registry" 
concept which is basically an associative array mapping from class names 
to fully qualified file names.
Every "classical" extension wanting to use the autoloader needs to ship 
a file called ext_autoload.php in its root directory (can be 
autogenerated with extdeveval). The core ships such a file as well, 
located in t3lib/core_autoload.php.
When the autoloader is started, the core files are automatically added 
to the registry by loading the t3lib/core_autoload.php file. 
ext_autoload.php files are loaded on demand when needed.

Resolving a class:
If the autoloader should load a class, it checks if the class starts 
with Tx_. If yes, it'll use the resolver for the new naming conventions. 
If no, it looks into the registry and checks if the class name is 
already in there (This happens in two cases: 1. it is implemented in a 
core file, 2. it is in an extension which has already been loaded).
If the class is not yet in the registry, then the class name is splitted 
into its parts and the extension key is resolved. Now, the entries of 
the ext_autoload.php file of the extension are added to the registry. We 
maintain a separate cache to speed up this process 
($extensionHasAutoloadConfiguration).

Building the ext_autoload.php / core_autoload.php:
We implemented a new extdeveval module to do this. It makes sense to 
pregenerate it, in order to speed up the autoloader and to make the 
autoloader as a whole work a lot more predictable. Basically, 
ext_autoload.php contains metainformation about an extension which will 
only ever change if the extension is restructured.
The reason why we (currently) use multiple files for the autoloader 
registry is that typically, we only need very few extensions to render a 
page. Additional caching can be implemented lateron if we see a need for it.

The autoloader is static to ensure maximum speed.

Notes:
This patch is part of a patch series to implement the autoloader. The 
patches have been worked out together with Olly, based on work by 
Dmitry, Ingo, Ingmar, Masi and Jochen.

Greets,
Sebastian
--
Gimme five!
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: extdeveval.patch
Url: http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20090426/2baac88b/attachment-0002.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: typo3v4-autoload.patch
Url: http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20090426/2baac88b/attachment-0003.txt