Stefano Mazzocchi wrote:
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.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.
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.
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 think of the Sitemap as a container for components (transformer, serializers, ...) as well. 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.
So it seems that "block-concepts" and custom granularity are application-level concerns.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.
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)?
cheers,
Ulrich
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
