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

Oliver Hader oliver at typo3.org
Tue Apr 28 00:08:35 CEST 2009


Hi Masi,

Martin Kutschker schrieb:
> Sebastian KurfŸürst schrieb:
>> 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:
> 
> Any reason isn particular why you didn't want to use the autloader
> Dmitry wrote and I have worked on later? It uses a caching method of
> class names and doesn't need any rewriting of existing code.

The patch of this RFC is base on your and Dmitry's first patches...

>> 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).
> 
> I agree with Dmitry that we should stick to tx_ in lower case. It looks
> alien in v4. But it's not so simple as that. We have t3lib (easy to
> handle), we have tslib (another easy exemption), we have the files in
> typo3/classes (I suggest to rename the classes typo3_ClassName). So far
> so good. That an extension class has to start with tx_ is not true, but
> in v4 the prefix user_ is also valid. And it doesn't tell you anything
> of the position within the extension (but you have dealt with this).

There are two possibilities:
* resolving the class file by class name (e.g.
Tx_Extension_Controler_ControllerInterface ->
extension/Classes/Controller/ControllerInterface.php by using the
underscore as separator)
* using a registry file that maps class names to PHP file names
The attached patch integrates both...

> Furthermore Ingo pointed out that the extensions foo_bar and foobar
> share the same extension key foobar. I couldn't think of resolving this
> issue.

If both extensions "foo_bar" and "foobar" are installed it's impossible
of course and both extension might have a "tx_foobar_pi1" - with or
without autoloader that won't work... If only one these possibilities is
used, it can be handled by the patch provided in a separate RFC #10986...

>> 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.
> 
> No need to do this, the autoloader patch mentioned has a PHP parser
> (Dmitry's original uses a regexp, mine uses PHP's tokenizer) to extract
> the class names (which worked fast and well in my tests).

The patch still uses the PHP tokenizer but does not have a full blown
file with all files anymore. That file you mentioned was serialized and
contained also extensions that did not use autoloading at all... (IIRR).

>> We implemented a new extdeveval module to do this.
> 
> Hm, I don' think it belongs to a module. It must be part of the real
> Core, so it can be generated any time. extdeveval shouldn't become
> necessary to run TYPO3.

Why? If a new file is added to the core, the core_autoload.php registry
has to be modified if autoloading should be used. Or otherwise the new
stuff follows a convention that can be used to (really) autoload a file
without using a registry map...

>> 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.
> 
> Oh my, Jochen also spent time on this?

ExtBase (implementing MVC in TYPO3 4.3 as backport of FLOW3) had an own
autoloader. And when system extensions begin to implement stuff that is
missing in the Core, it clearly states, that it should be integrated
into the Core...

olly
-- 
Oliver Hader
TYPO3 Release Manager 4.3


More information about the TYPO3-team-core mailing list