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.
Ok.
/Daniel
