avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <u...@denic.de>
Subject Re: Requirements for implementing Cocoon Blocks
Date Wed, 08 Jan 2003 10:12:45 GMT
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.

> 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, 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.

> 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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message