[TYPO3-mvc] Proposal: mixed-ins for extbase

[Franz Koch]

Hey Helmut,

>> I think this has to be possible via whatever approach - so the current
>> concept is not yet a final solution and needs some more thoughts.
>>
>> Just an example. Imagine you're extending a existing extension and add
>> some new properties etc. Now imagine the domain model itself contains
>> some domain logic you're additions also depend on. So you need a way to
>> "hook" in there.
...
> I totally understand that usecase, but how far should we go for extbase?
> Should it be possible to call the "original" method out of the mixin
> method that overrides the original method? Should the mixin method be
> called before or after the original method? How should this be
> configurable?

I know that this is not that easy, but I think I have a easy to 
implement idea:
If we decide to provide such a feature I think it's sufficient if the 
"parent" method could be called from within the mixin - so that 
"parent::methodname" would work. This "magic" doesn't have to happen 
automatically - it would be ok I think if you can register 
"overrideMethods" for mixins. If such a method is registered, the method 
in the default class is beeing renamed (maybe via a hashed name or just 
prefixed) and the string "parent::methodName" is then replaced by 
"self::renamedOriginalMethod" in the raw class file of the mixin. This 
should be quite fast as well and can easily be cached without any 
complications.

There might come up issues on cases, where multiple mixins would like to 
extend a default method, but if we merge the resulting mixin-class after 
every integrated mixin and always use this as the basis for the 
search/replace for the method names, this should work just fine up to a 
certain degree.

What do you think?


> I mean, it could perfectly be covered by the possibilities of AOP.
> However I'm not willing to implement AOP for extbase and I'm also not
> sure if this would be the way to go.

AOP would be too much for extbase I think (we need to hold back some 
gimmicks for FLOW3 ;) ), and the described usecase might not be needed 
for 90% of the extensions - so we should aim for a easy and fast 
solution, just providing some basic features for this.

> So the question is, do we want the solution I advertised and benefit
> from it as far as it goes (beeing able to _add_ functionality and
> properties), or leave it as is and wait until a better solution is in
> place or FLOW3 stable is released.

Don't get me wrong - I'm totally in favor of this mixin concept as it 
sounds like a good concept - I just wanted to open up your mind for this 
usecase if it hadn't been thought about before.
The only thing I'm not sure about is if the magic should happen in the 
autoloader. We should encourage to use the objectManager as this one 
will probably also support DI in the near future - so it would be fine 
to have it there, too I think.

-- 
kind regards,
Franz Koch