cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Some notes about the "Real Blocks" issue
Date Mon, 18 Oct 2004 08:01:04 GMT
Ugo Cei wrote:

> Il giorno 17/ott/04, alle 17:22, Daniel Fagerstrom ha scritto:
>> data. In Spring you must as well supply wiring information about how 
>> the component is connected to other components thru setters. You need 
>> to describe the life cycle, if there are any initialization and 
>> destruction methods of the component and the names of them. You need 
>> to describe the life style, if it is e.g. a thread safe or poolable 
>> component.
> I don't want to go into a debate on Dependency Injection versus 
> Locator (there's an article by Martin Fowler out there that talks 
> about the pros and cons of each approach). 

I have read Martin Fowler's article and in the "general" case he finds 
constructor DI slightly better than property DI, and he find DI slightly 
better than Locator. I find his arguments reasonable.

For Cocoon, I share Sylvain's view that constructor DI for required 
components and property DI for optional components might be a good 
approach. However, IMHO, it would not give enough advantages to be worth 
any back compatibillity, a prolonged period of instabillity or (at least 
for me), the effort. And as I allready have explained, I find the 
"standard" approach for configuration files in Spring problematic.

That is my current view of the subject, but I'm quite new to the subject 
of type 2/3 containers, and very interested in other views of the 
subject. I think that it would be quite usefull to discuss the pros and 
cons of the various DI  and Locator approaches in a concrete Cocoon 
context. I would also find it intersting to learn more about if and how 
AOP could be used for making the component management in Cocoon better.

> I just want to point out that using DI does not rule out the 
> possibility of doing lookups. In Spring, for instance, you can 
> implement the ApplicationContextAware interface and get handed an 
> ApplicationContext that you can use to look up other components a-la 
> Avalon.



View raw message