Re: Requirements for implementing Cocoon Blocks

Stefano Mazzocchi wrote:
> 
> Cocoon needs a way to deploy cocoon-based web application at runtime.
> 
> We could do this following the WAR model of the Servlet API, but we aim 
> at more advanced stuff.
> 
> So I want Cocoon to be the first web-oriented technology to follow the 
> CoP paradigms.
> 
> These 'webapp components' will be called "Cocoon Blocks" (or, in short, 
> COBs). These blocks will be behavioral and polymorphic. Means that I can 
> have a block A (say a webmail webapp) depend on a block B (say a skin 
> implemented using XSLT stylesheets).
> 
> So, block A depends on block B implementing some services to skin stuff. 
> This isolates concerns and make webapp composition component-oriented 
> following the good old IoC and SoC patterns.
> 
> Downside: currently, no Avalon container allows that kind of flexibility.

No Avalon container is web/servlet-enabled, that is IMHO the main 
problem. Some folks report that Sevak can provide web connectivity for 
Phoenix, but others haven't gotten it to run.

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

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

Now, suppose we were to say that our CoP-oriented web application 
framework does not need a block-concept, it would be sufficient to have 
a component concept. Then we could just use Avalon's existing component 
concept and would not have to worry about containers. This is not a 
theoretical idea, there already are application frameworks that use 
Avalon's component model to build applications following the CoP 
paradigms. As stated above, what's missing is the Web/Servlet part, but 
CoP-oriented web application design is possible and has been done with, 
for example, a combination of Avalon, Phoenix and X:Forge.

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?

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

cheers,

Ulrich