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 11:50:45 GMT
Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:


>> Add your reasons.
> Since Avalon came to life and I came to love it, I've had long fights 
> with some of my colleagues at work to convince them to use it, in 
> order to have robust architectures. Their argument was that they 
> didn't want to use Avalon because of its viral nature: once you start 
> using it, you have to use it everywhere and your code no more can be 
> used outside an Avalon container. Although I wanted to promote Avalon 
> as a way to have an homogeneous way to hold the various parts of a 
> project, I also understood their arguments.

It hurts when loved ones fails us ;)

> State of the art has evolved, and strangely we can consider that the 
> writing style that DI brings us is in some ways going back at a time 
> where COP did not existed, where people were writing spaghetti plates 
> dependencies. DI simply allows us to have spaghetti plugs in our 
> classes and it actually wires the spaghetti plate, without enforcing a 
> rigid structure where you must fit or go away. In some way, DI allows 
> to manage the chaos.
> Now I understand all your concerns about the revolution this may lead 
> to, and I recognize I may be a bit over-enthusiastic. If you read the 
> archives (e.g. [1]), I wasn't that happy at first.

My view seem quite close to your in [1], it will be interesting to see 
if I also will see the light within the next few mounths ;)

> But my mind evolved as I was looking at Spring and all the cool 
> features it provides. Sure, these features may only be really useful 
> for business logic, but why not also for Cocoon components?

Yes, it would be interesting to find out. But I really think we can live 
without yet another "next generation" fork. If it could be found out in 
an evolutionaty way, I'm all for it.

> This is still theoretical, but I have the feeling we can make this 
> revolution in a smooth way, by facading a Spring container with an 
> Avalon container implementation. I'll spend some times on this in the 
> coming weeks, and we'll see what comes out of it.

Sounds like a good plan to me.


>> The death of Avalon doesn't force us to do anything in the short 
>> term. Actually it takes away part of our previous problems, no one is 
>> going to do anything hostile about the API anymore. And if we feel 
>> that we must develop it we can steal it without upsetting anybody.
> You're totally right. The death of Avalon makes us free to do whatever 
> we want with these APIs. Now the question is: do we want to live with 
> a dead thing when we have more lively alternatives in front of us?

Decreasing the Avalon dependency would certainly be a good thing. I just 
wanted to point out that we don't have to panic.

I think a reasonable sequence of steps would be:

1. Make it possible to use components that are managed by an external 
container from within Cocoon components. This could probably be 
implemented by letting the Cocoon component manager call an external 
component manager for components that it does not handle it self. The 
coupling to external component managers could maybe even be 
configurable, to make the system future proof.

Wouldn't this take a way the dependence on Avalon interfaces for most 
user needs. If you are going to write new sitemap components you will 
still need to use Avalon interfaces. But IMHO, the need of writing 
stemap components is much reduced today compared with the situation 
before. You can do most of your integration work using flowscripts. If 
we could find a good and common way to write new template languages (a 
Jelly generator/transformer maybe?) we could reduce the need for writing 
new sitemap components even further. I guess

2. Make it possible

> Also, from a marketing point of view, how will you explain to a 
> customer that the foundations Cocoon components are built upon are a 
> project that has been closed?
> Sylvain
> [1]

View raw message