Ulrich Mayring wrote:
Right. And I think this will remain the case (I don't see any reason to change this)Stefano Mazzocchi wrote:Ulrich Mayring wrote:No Avalon container is web/servlet-enabled, that is IMHO the main problem.
No. Cocoon is already completely abstracted from the servlet context. We are not asking for an avalon container to be servlet-aware since Cocoon provides that abstraction.
Cocoon provides the abstraction, because neither Avalon, nor any known container does.
My thought was that, if such a container were available, the whole Cocoon-block thing would be easier to do in terms of deployment and management.True. And my lazy butt tells me so too, but I'd rather spend my time writing additional and cocoon-specific code than fighting here to get something included in Avalon.
Expecially since enough stuff moved from Cocoon to Avalon that somehow "polluted" the original Avalon model.
Not all CoP levels might belong to Avalon, we must understand that.
Yes, both are possible, but my lazy butt would go for the second (which means: less code to write and to maintain)The idea is that the avalon container is general enough to allow container users (cocoon) to extend it for its needs.
Yes, makes sense. I guess you mean "extends" as in Java inheritance: 1) Avalon --> CocoonContainer --> Cocoon components There would also be the possibility to do something like this: 2) Avalon --> AvalonContainer --> CocoonContainer --> Cocoon components
I don't know whether that is what Cocoon wants, but it would have the advantage that a CocoonContainer could run alongside a XYZ-container and presumably all installed components could communicate via the AvalonContainer.Exactly my thoughts. The idea is to handle back to the Avalon Container everything that it can handle by itself and have the Cocoon Container take care of those things that don't make sense in a general Avalon context.
I'm not asking for Avalon to resurrect the concept, but I do believe there is a need for different granularity of component models and my design outline on cocoon blocks shows that.
Cocoon definitely needs a different granularity.
I'm glad you acknowledge that.
I think of the Sitemap as a container for components (transformer, serializers, ...) as well.
True.
An XML page is also a container for XML elements, if you will, and a Cocoon user probably needs to deal more often with granularity on this level than on an Avalon level.
Yes, I totally agree with you.
Not necessarely. In the past, the concept of 'block' as a collection of components was supposed to be the base for server assembly, but Phoenix changed the picture.So, to me the interesting question is: what do we give up if we give up on a block-concept and instead rely only on a component concept?
So, if we give up the concept of blocks, we give up the ability to mix, into the same operational unit, components described with different semantics (say, java objects and sitemaps)
This is not a big issue, really and something that can easily be addressed at the application-level.
So it seems that "block-concepts" and custom granularity are application-level concerns.
I still like the concept of blocks, even in an Avalon context and I would like to see them resurrected, but I don't care enough to fight for it.
so, at the end, if the avalon container supports blocks, great, otherwise, the cocoon container will and will use the avalon container only for the component-related stuff.
To be entirely honest with you, I haven't really thought about implementations that much because the realm of avalon containers is shaky and confused to say the least and I wanted to wait for the dust to settle down a little.What I ask is the ability to extend the container easily with components which are not implemented as java objects but with other, application-specific constructs.
Fair enough. But what about the existing Avalon contracts? Let me draw a diagram:
Avalon contracts
AvalonContainer --------------------> Avalon components
|
|inheritance
|
V Cocoon contracts
CocoonContainer --------------------> Cocoon components
It seems to me that the CocoonContainer would also inherit the standard Avalon contracts, but that not all Cocoon components could fulfill them (i.e. if they're not implemented as Java objects, as you said)?
Also, Stephen was interested in implementing parts of the requirements in Merlin so I want to see how that works out and how he plans to solve those things.
Hopefully, also, Fortress and Merlin will merge... and a that point we'll have a container to base our own implementation on.
But as far as implementation goes, this is still up in the air.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
