[TYPO3-dev] Defending the XCLASS, proposing smaller classes

[Ernesto Baschny [cron IT]]

Elmar Hinz schrieb am 09.02.2006 00:16:

> in the thread "SOLUTION (?) : Multiple XCLASS inheritance"  a lot of people
> dammed the XCLASS. I guess that most of this people think in this pattern:
>
> (...)
>
> To summerize:
> 
> Conflicts are rather a problem of the wrong usage ot the differnt technologies.
> They can not be solved by simply changing the technologies. We must change our
> habits to use the technologies.
> 
> One mayer problem is, that classes in TYPO3 are often to big. If a class is big
> it is more likely that conflicts will result if different extensions try to
> alter functions in it. The best way to reduce conflicts is to write smaller classes.

I agree with Elmar, I think this is the big main issue here. The top
most XCLASS'ed classes in TYPO3 are very big, so the area of potential
conflict is high. Most extensions just need to replace or add
functionality to an existing TYPO3 method. We need to make sure they can
still do that without having to add hooks on all functions.

Multiple extensions plugging to the same hook are potential conflicting
too, as most hooks don't handle these conflicts (which they could, if we
had a more defined interface for hooks!).

I've already proposed trimming tslib_cObj some time ago, by out-sourcing
most of the functionality to extensions. One class that can handle
IMGTEXT, another that handles FORMs, another yet that handles stdWrap,
and so on. So if one extension then XCLASS'es the class "cObj_FORM",
another one can still XCLASS "cObj_typolink" and they won't bother by
each other. If two of them want to XCLASS cObj_FORM we have a potential
problem anyway no matter what architectural way of doing it you choose.
This is where specific hooks with consistent interfaces can be added to
have more fine-grained extensibility.

The major task seems to be to recognize potential splitting-points in
the code and do the work.

The same technology will apply when we start doing some MVC work,
splitting view and controller functionality for most TCA stuff. Generic
top-level "view" classes should have hooks and/or out-source "helper"
functions to separate classes, which can be XCLASSed.


Cheers,
Ernesto