cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [RT] Cocoon component container and excalibur
Date Tue, 08 Jun 2004 07:15:30 GMT
Pier Fumagalli wrote:
> 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...

With Fortress you can implement your own lifecycle interfaces. I'm
not sure but I think we can solve your problems from above with
that. It is even possible to use setter injection, so something like
class BlockA {
   void setBlockB(Block blockB);
could be done (it's a dump example which should just express my
thought, don't take it for the real solution).

I'm confident (although I haven't really looked deep into it) that
with own lifecycle interfaces and a lookup mechanism that takes
class loading into account, we have everything we need. The first
one is already supported by Avalon and I think we can add the
second one to Avalon as well.


View raw message