[TYPO3-dev] Detecting XCLASS conflicts

[Dimitri Tarassenko]

Bernhard,

On 3/22/06, Bernhard Kraft <kraftb at kraftb.at> wrote:

> > If the used XCLASSed
> > function doesn't fit for some extension, then you must touch to the
> > source code and made ux_ux_some_extenstionClass from
> > ux_some_extensionClass? Correct?
>
> this get's done by the XCLASS-Manager.

> It rewrites the code of the extension automaticall if you "move it to the right" and makes ux_ux_
> out of ux_
>
> It also changes the XCLASS inclusion lines in the ext_localconf.php file of the moved extension so
> it XCLASSes the parent class:
>
> $TYPO3_CONF_VARS['XCLASS']['BE']['t3lib/class.t3lib_tceforms.php'] = t3lib_extMGM: ....
> get's rewritten to:
> $TYPO3_CONF_VARS['XCLASS']['BE']['ext/someext/class.ux_t3lib_tceforms.php'] = t3lib_extMGM: ....

Just the fact that it detects the conflicts is already awesome!

Now, couple of problems/questions that I see with this:

1. I understand you need to re-run and reconfigure every time you
update one of these "chained" conflicting extensions from TER?

2. What happens if the two conflicting extensions override the same
method of a parent class? "Chaining" is somehow implementable,
however, what happens when one "chains" the parent via parent:: call,
and another one rewrites the method completely? (Some older classes
typically have 2 methods, init() and print_content(), 400-500 lines
each ;).

and the last one - were you planning to publish this ext in TER -
cause I couldn't find it there, and if not would you mind if I grab it
off the test site as t3x?

--
Dimitri Tarassenko