[TYPO3-ect] News about XCLASSES?

[Joerg Schoppet]

Elmar Hinz wrote:
> Ernesto Baschny [cron IT] wrote:
>>
>> The idea in 5.0 will be to have components and objects, so extending
>> their functionality in extension seems a natural thing that we might
>> accomplish. As those classes should be much better organized (and
>> smaller), a framework based on the decorator or some other similar
>> pattern might be a welcome alternative for the XCLASS.
>>
> 
> I have made experiments with an architecture, where every instantiation 
> of a class is done by a "factory" and needs to implement an "interface" 
> (PHP5). This way every class can be replaced by customized classes.
> 
> 
> 
> But look into makeInstance():
> 
> 3984 function &makeInstance($className)    {
> 3985  return class_exists('ux_'.$className) ?
>               t3lib_div::makeInstance('ux_'.$className) : new $className;
> 3986 }
> 
> 
> It does something very similar, only that PHP4 doesn't know interfaces. 
> (Mark: this Funktion doesn't require that the XCLASS inherits form the 
> extended class. You could also use a decorator.)
> 
> But the handling is very rigid today. There can only be one ux_-class here.
> I think we could provide more flexibility in this point by using a 
> registry. Then we could provide some logic that decides which of the 
> registerd alternatives to use. The logic itself could be specified on 
> base of the incomming classname by functions or even by extensions.
> 
> Result: We still have the point of conflicts, but we gain a programmable 
> system to specify how to solve the conflicts.
> 
> Regards
> 
> Elmar
> 

This is exactly what I'm developing actually. I have a registry-object. 
Each extension can register over there ext_localconf.php-file extensions 
for existing classes (including dependencies). If I need a new object, I 
"ask" a factory method of the registry-object to create me the object 
with the needed functionality and the method then, using decorators, 
return me the needed object.

Jörg