Re: Requirements for implementing Cocoon Blocks

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

If it's possible I'm all for it. So far Cocoon is a major customer, 
maybe there are some others, I don't know. But once you have a number of 
major customers like Cocoon my guess is you won't be able to make all of 
them happy with a über-container. But, as I said, I'd love to be proven 
wrong :)

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

I was talking about application development in general.

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

What do you mean by arbitrary partitioning? There already is arbitrary 
partitioning by way of Avalon components. How much more arbitrary do you 
want to become? For example, do you want to do something like this:

arbitrary_code --> Java class
Java classes --> component
components --> block
blocks --> application

Where you have four different ways of partitioning? That would seem not 
very arbitrary - the developer has to adhere to four different contracts 
and what if he needs a fifth partition?

Arbitrary partitioning to me would mean something like this:

arbitrary_code --> component
components --> component

While this is more elegant, because it has only one contract and the 
developer can be real arbitrary, it does not seem very useful to me.

cheers,

Ulrich