Re: Requirements for implementing Cocoon Blocks

Ulrich Mayring wrote:
> Stefano Mazzocchi wrote:
>> Result: Cocoon will *NOT* upgrade to a more modern Avalon container 
>> until all the Cocoon Block requirements are met. (we don't want to do 
>> the job twice!)
> 
> Which Avalon container does Cocoon use right now?

ECM (but I believe very much modified). Also ECM is a 
"pseudo-container", really.

>  > Detailed description of Cocoon Blocks
>  > http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> 
> Ok, in this document there are some requirements, that are 
> Cocoon-specific, such as Sitemap connectivity. I'm not sure how that 
> could be addressed in an Avalon container or whether it even should.
> 
> Avalon (framework) provides a component model, it does not provide a 
> block model (a block being a collection of components here). Blocks, 
> whether they be Cocoon blocks or Phoenix blocks or whatever else, 
> require a container that internally manages Avalon components.
> 
> IMHO there can never be a container, that makes everyone happy, because 
> the container itself is not only a framework, but also an application. I 
> tend to think that any application that wants to provide its own 
> deployment/management/CoP functionality has to write its own specific 
> container. I'd love to be proven wrong, though :)

Probably. But the idea is to do a proper extraction of that container 
framework and do as much work as possible within the avalon scope. Peeps 
are talking of building "profiles" on top of such a framework to handle 
more specific needs, with easy tweaking of those profiles for your 
application-specific needs. SoC, really.

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

are you referring to cocoon or in general? In general application 
decomposition, we often find logical partitions of the application into 
components, and then logical partition of those components into 
subcomponents, up to a level where a subsubsubcomponent becomes to small 
as to warrant the component management overhead.

The phoenix block model (now mostly deprecated) was sort of like
component-->block
subcomponent-->component

for the above paragraph. Not clear to me yet what the cocoon block model 
is. The trick is to find a way to allow arbitrary partitioning without 
making the supporting code too complex. avalon-sandbox/assembly is work 
in process which (among other things) aims to do that (IIUC).

> And are those features that we give up on application-neutral or 
> application-specific (like Sitemap concerns)?

arbitrary partitioning is an application-neutral concern. I'm guessing a 
cocoon block model would be application-specific, with a large part 
addressable by application-neutral stuff. We need to figure out how 
avalon can provide the application-neutral stuff, and also make it easy 
for cocoon to put the application-specific stuff on top of that.

my take on it so far, cheers,

- Leo