[TYPO3-mvc] [TYPO3-dev] URGENT CHANGE REQUEST: Dependency Injection Problems with ExtBase 1.3.0RC1

[Michael Knoll]

Hi Sebastian,

just to give you a final note on that: We found out, that there is 
actually only one class where we have the problem and changed the method 
name.

We thought about what should be added to the concept and came to the 
point that we have to think about the concept of DI in our extension again.

Still the problem occurs, that we have a lot of methods called 
'injectXYZ' and it would be a mess to rename them. So setting DI off for 
each method using a '@noDI' annotation would be the easiest solution for 
us... but it's not that urgent anymore... let's talk about that some day 
soon :-)

Thanks a lot for your immediate help and all your work on ExtBase!

Hope to see you some day soon in Karlsruhe

Michael




Am 24.01.11 11:25, schrieb Sebastian Kurfürst:
> Hi Daniel,
>
>> Is there a reason, why the ExtBase DI is triggered by the methodName and not
>> explicitly by an annotation like "@inject"? A negative annotation like
>> "@doNotUseExtbaseDI" could be implemented with a single line in
>> classInfoFactory::getInjectMethods... With annotations we can use extbase-DI
>> where it is possible and our custom DI where it is not.
> Yeah, because in FLOW3, it also happens automatically if you follow the
> inject* method name conventions. That's why I won't change this for
> Extbase either.
>
>> In the extension Michael talked about, we use factory classes to build our
>> objects. This is not supported by extbase-DI, which (if i read the code
>> correctly) just instantiate an object by t3lib_div::makeInstance(). I just
>> thought about a TS configuration option for that (forge wiki example):
> +1, a patch on this is welcome :)
>
>> What about the feature to define the class names on a per-extension basis as
>> mentioned in the wiki? Are there plans to do that in the near future?
> Unfortunately, this is a really difficult one, because of multiple
> reasons, which have to do with singletons:
> - As singletons are *request-global* and not *plugin-global*, two
> plugins right now use *one singleton*. Thus, one could not re-wire the
> DI in between extensions; as one would need to throw away certain
> singletons and re-instanciate them.
>
> - Furthermore, there are certain classes early in the bootstrap (mainly
> the Configuration* subpackage) which cannot be replaced by DI, as the
> configuration is not loaded yet at this point.
>
> Greets,
> Sebastian