cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <...@apache.org>
Subject Re: [RT] Some notes about the "Real Blocks" issue
Date Sat, 16 Oct 2004 11:40:49 GMT
Il giorno 16/ott/04, alle 11:14, Guido Casper ha scritto:

> Ugo, can you explain what exactly are the dependencies on Spring? My 
> rather limited) understanding is, that we primarily would use Spring's 
> BeanFactory. As the BeanFactory is:
> a) designed to not introduce any dependency for your components
> b) rather trivial to re-implement
>

Looking at the current Butterfly code in SVN, there are 70 Java classes 
(not counting tests). Of those 70 classes, only two do an "import 
org.springframework...".

One is the SourceResolver, which implements ApplicationContextAware in 
order to resolve paths relative to the servlet context. The other one 
is ButterflyServlet, which fetches a Spring application context from 
the servlet context and passes it to the sitemap. Well, actually I am 
cheating, since the implementation the sitemap processor is a Groovy 
class, and that does lookups on Spring's bean factory, so make that 
three classes out of 71.

To sum it up, all the sitemap components can be designed to be use DI 
exclusively, without dependencies on the container. Things like the 
sitemap processor, which needs to lookup components and assemble them 
dinamically, will probably need to have some degree of dependency, 
unless you want to define each pipeline via DI. I think this would be 
quite awkward, if at all possible. Of course, with a proper design, 
even these dependencies can be neatly tucked away in a handful of 
classes. The main usage is calling BeanFactory.getBean(String name) and 
encapsulating that is an absolute no-brainer.

Hope this answers your question,

		Ugo

-- 
Ugo Cei - http://beblogging.com/

Mime
View raw message