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

[Dennis Cheung]

Hi all,

I think. Whatever you call it, it is a hook/extension-point in general
description.

I have rewrite cObject for myself. It use function name.
e.g.
$name="IMGTEXT";
$func=$this->lookupTable[$name];
$content=$this->{$func}($content,$conf);

It works, fast, and look goods for maintance.
Even I can quickly (re)define tag. I don't have to rewrite the "switch".

Also, if it defined an array of function name(with same parameter
set.) for stdWrap.
and let stdWrap loop for it. You may also define more function here.

Whatever anything typo3 will use. At least, it must be an function,
not a variable.
XCLASS syntext is too foolish. It don't detect any duplicate XCLASS.
And I can't sure which class will be used finally.

It should be configable in BE ext. mananger. Like a service, can take
the control.

----
Beside, who was said no one will interested to extends t3lib_div (this
thread or another thread)??
It is not a XCLASS, and it use static function. I have to MODIFY the
source myself.
(I wanted to keep source typo3 unchanged, and I can quickly update it.)
e.g.
 make get_dirs()  will skip CVS and .svn
-----


The another real problem of XCLASS is.
It do not affect others class extends on the base class.
e.g.
you have an ux_basicfilefunc extends basicfilefunc.
But there are another "adv_filefunc extends basicfilefunc".

What you have done in ux_basicfilefunc is nothing related in adv_filefunc.
You can found a few class like this in typo3 core.


Dennis


On 2/9/06, Ernesto Baschny [cron IT] <ernst at cron-it.de> wrote:
> 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
> _______________________________________________
> TYPO3-dev mailing list
> TYPO3-dev at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev
>