[TYPO3-dev] Detecting XCLASS conflicts

[Bernhard Kraft]

Dimitri Tarassenko wrote:

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

It took me 4 days and night to code this monster ... please never review the code ;)


> 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?

If some company(ies) would support this somehow I could start to implmement some kind
of "extension-combination-description" format which can get saved and loaded in the
XCLASS manager (XCM) and which describes staticall how the XCLASSes shall get inherited ..
so when you then update an extension again the old settings will get applied ... you
would have to visit the XCM just once and hit an update button.

Those "description-files" could get bundled in the form of a T3X and get uploaded to
TER. So it would be possible to share configurations of working XCLASS-setups of differnent
extension combinations.

I think the afforded amount of money would be in the order of about 1.500,- E to at least
somehow cover the amount of time it took me to implement.

> 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 ;).

The problem here is that normally when you modify a method you leave it's API
the same ... (at least you should !!! :) ... this means extending two different
methods wont hurt in most cases.

But the problem is when 2 methods extend the same method it is not clear what shall
happen (which one shall get called first) what shall happen when it returns what ...
to define such a lot of criterias would afford quite some knowledge of what the methods
do.

But of course you could implement some kind of syntax:
-----
sampleext1:method != 0
< sampleext2:method
-----

which could mean first call ext1's method and only if this one returns != 0 call ext'2 method and return
it's value .... but this could get complicated ...


> 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?

Pherhaps some time ... it is still not decided to be stable enought ... and I would of course
like to get some money for it .... my motto is "think-open" -- that's in fact my companies name -
I'm am a freelancer since last Novemebr -- and this motto means that I usually do some nice stuff
and when someone finds it is nice he can pay me for it and I put it in TER. Nice not ?
And of course the sponsor will be honored in the docs ...

I can't do as I did when I was employed at my old company ... at this time I made extensions "just-4-fun"
in my spare time ....


But of course you can download it ... I will not send you a bill :)
But only under the condition I get a little usability/bug/"which extensions work together" report :)
just as much as you find out while experimenting.


greets,
Bernhard
-- 
----------------------------------------------------------------------
"Freiheit ist immer auch die Freiheit des Andersdenkenden"
Rosa Luxemburg, 1871 - 1919
----------------------------------------------------------------------