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
smime.p7s
Description: S/MIME cryptographic signature
