Re: Requirements for implementing Cocoon Blocks

Ulrich Mayring wrote:
> 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. 

Right. And I think this will remain the case (I don't see any reason to 
change this)

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

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

Yes, both are possible, but my lazy butt would go for the second (which 
means: less code to write and to maintain)

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

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

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.

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.

>> 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)?

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.

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]>
--------------------------------------------------------------------