[TYPO3-50-general] Improvment for Injections?!?

[Malte Jansen]

Hi Robert,

is already fully implemented?

Cheers,

Malte

Robert Lemke schrieb:
> Hi Malte,
> 
> I changed my mind (a bit): FLOW3 now supports Property Injection - not with
> public but with protected properties!
> 
> See http://flow3.typo3.org/documentation/reference/object/
> 
> Cheers,
> robert
> 
> Am 12.01.2009 um 09:38 schrieb Malte Jansen:
> 
>> Hi Robert,
>>
>> ok
>> it just came into my minde...
>> Perhaps DEV3 could add some autocompletion for injections, so you don't
>> have to write so much simluar code.
>>
>> Cheers,
>>
>> Malte
>>
>> Robert Lemke schrieb:
>>> Hi Malte,
>>>
>>> Am 11.01.2009 um 19:46 schrieb Malte Jansen:
>>>
>>>> it would be nice get some feedback...
>>>> Bad idea? Not possible? Perhaps later? We working on it ;) ?
>>>
>>> sorry, forgot about this thread.
>>>
>>>> Malte Jansen schrieb:
>>>>> Hi,
>>>>>
>>>>> I just tested the AOP and discovered, if you just use an aspect for
>>>>> injecting a class.
>>>>>
>>>>> So what about some injecting the Classes via a DocComment-Tag-Syntax?
>>>>> e.g.
>>>>> @inject $objectFactory F3::FLOW3::Object::FactoryInterface
>>>>> @inject property F3::MyPackage::MyClassInterface
>>>>>
>>>>> There is no autocompleting, but the outline of a class has less 
>>>>> entries
>>>>> and injecting something is more or less more an AOP-aspect, than
>>>>> belonging to a model.
>>>>>
>>>>> And if you want to test a class, you can use the old-fashioned-syntax
>>>>> (implemented somehow as aspect):
>>>>> public function 
>>>>> injectObjectFactory(F3::FLOW3::Object::FactoryInterface
>>>>> $objectFactory);
>>>>>
>>>
>>>
>>> Although it sounds tempting, there are a few issues with this solution:
>>>
>>> 1. Readibility / Black Magic
>>>
>>>    All code a class uses internally should actually be found in the 
>>> class
>>>    itself (or one of the parent classes). It would be too much magic if
>>>    the class code referred to $this->objectFactory but there is no such
>>>    property defined and no method which fills that property.
>>>
>>>    Cross-cutting concerns, which are extracted by AOP, are a different
>>> thing:
>>>    Although they introduce new functionality, the target class does not
>>> refer
>>>    to it - it doesn't even know about it.
>>>
>>>    Although it could be argued that annotations are well enough
>>> readable for
>>>    this mechanism, injection of dependencies is simply not a 
>>> cross-cutting
>>>    concern but an important part of the class construction.
>>>
>>> 2. Loss of contract
>>>
>>>    No matter if your class implements an interface or not, third party
>>> code
>>>    will rely on the set of public functions your class provides. If this
>>>    code wants to call an inject method (or a regular setter), it doesn't
>>>    know for sure if it exists.
>>>
>>> 3. Testing
>>>
>>>    Most importantly, tests should always work without the AOP
>>> framework, because
>>>    only this guarantees that you're testing the code you want (and not
>>> the woven-in
>>>    functionality). You write:
>>>
>>>>> And if you want to test a class, you can use the old-fashioned-syntax
>>>
>>>    You always want to test a class of course, therefore you always
>>> would have to
>>>    use the old-fashioned syntax.
>>>
>>> The basic idea you had is not wrong though, it surely would be nice to
>>> simplify
>>> setter injection. A cleaner but still not clean approach would be to
>>> declare
>>> public properties which are then automatically filled from outside:
>>>
>>>   /**
>>>    * @var F3\FLOW3\Object\Factory\Interface
>>>    */
>>>   public $objectFactory;
>>>
>>> But I never really liked that solution because it conflicts with our
>>> rule of not
>>> having public properties at all.
>>>
>>> So, I'd say, for the time being it's nothing I'd like to see support for
>>> in FLOW3.
>>>
>>> Cheers,
>>> robert
>>
>> _______________________________________________
>> TYPO3-project-5_0-general mailing list
>> TYPO3-project-5_0-general at lists.netfielders.de
>> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-project-5_0-general 
>>
>