cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: [RT] Cocoon component container and excalibur
Date Thu, 03 Jun 2004 09:58:03 GMT
On 3 Jun 2004, at 07:30, Gianugo Rabellino wrote:

> Anyway, the thing is we are considering moving towards a container 
> that doesn't follow even Framework's specs. But in that case, be 
> assured that there will be some kind of compatibility.

On 3 Jun 2004, at 07:40, Carsten Ziegeler wrote:

> I don't want to freak out again but if you look at the discussions
> about the block implementations, there were a lot of discussions
> to also remove the framework api from the block system. So if you
> want to use the benefit of blocks, you can't use the avalon
> framework api for your components. And I still think this is bad.

There are some core problems with the Avalon APIs which are orthogonal 
to blocks deployment...

As a first, all selections are based on real-java-objects (tell me how 
to "require" a block that has no components, like a Forrest Skin and 
I'll be happy).

Second of all (but I think this is solvable) component selection is 
kinda weird and goes totally against the IOC principles.

A block should require another block, it should not by any means 
"select" a block as we do now with component selectors)...

It's kinda mixed at the moment, I'm given a logger, I'm given a 
configuration, but I have to ask for a component?

Cocoon did a _VERY_ good job in implementing component selection by 
extending the ECM itself and having all its blocks to be given things 
(I'm given a SourceResolver, from a Generator point of view), but if 
you take one step back, well...

And (of course) this is related to the second problem I outlined in my 
longish email before...

The Cocoon approach can be used in the new framework, and we can have 
Cocoon itself (only central point knowing what's going on both in 
Avalon and Kernel) to merge those two worlds and make them work 
together...

And, Carsten, I too still think it's bad if we don't somehow reuse all 
that code that we have out there built on Avalon... I don't like to 
re-write stuff when it's not absolutely needed...

	Pier



Mime
View raw message