cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: What is the deal with "blocks"
Date Thu, 28 Dec 2006 23:08:37 GMT
Mark Lundquist skrev:
> Hi, I've been wanting to ask this question in one form or another for at 
> least the last year, but never gotten around to it until now... at 
> various points I've scanned the archives for the early discussions about 
> "real blocks", and skimmed discussions btwn. Daniel and others on the 
> dev list as they went by, which by that time were too advanced for me to 
> really follow...
> There are two different meanings of "block", right? :-)

It is somewhat right, but not entirely.

> The first sense of "block" denotes an optional part of Cocoon, e.g. 
> "forms", "batik", "html", etc.).  In 2.1 we would configure 
> to include or exclude blocks from the build.

A block in Cocoon is analogous to a plugin in Eclipse or a bundle in 
OSGi. It is a container, containing Java classes, resources and services 

This has been the case for our implementations all the time and we have 
no plans to change it. Considering packaging, deployment, dynamism and 
features the Cocoon blocks are improving:

In Cocoon 2.1 a block is a directory with source code and some external 
configuration files that need to be deployed with a fairly complex ant 

In Cocoon 2.2 a block is just a jar which follows some conventions. If 
you drop a block into WEB-INF/lib in a "Cocoon webapp" and start it, the 
block will be automatically deployed.

In the next generation of Cocoon, a Cocoon block will be an OSGi bundle, 
this will provide classloader isolation and infrastructure for 
dynamically installing, updating and removing blocks in a running system.

> The second sense — I'll refer to it as "Block", with a captial "B" — is 
> apparently something different, with new protocols, etc., which is 
> implemented by the cocoon-blocks-fw module.

In the original proposals for the block architecture a block also 
contained a special "block sitemap" that could be called from a "block 
sitemap" in another block using a special "block protocol".

While working on implementing the original block proposal I after a 
while come to the conclusion that the "block sitemap" aspect and the 
"block as a container of classes, resources and services" aspect could 
better be considered as separate concerns and be implemented independently.

Later I decided that there was nothing special with the "block sitemap" 
processor it is just another service that a block can provide. I also 
generalized it to make it possible for a block to provide a servlet 
service rather than a more specialized sitemap processor service. There 
where no reason for limiting a block to contain only one servlet service.

The cocoon-block-fw module contains the infrastructure for servlet 
services. The most important class is the BlockServlet it is the class 
that you configure in your Spring configuration for providing a servlet 

A BlockServlet can be configured to refer to other BlockServlets. Inside 
the BlockServlet an internal BlockContext is setup, the BlockServlets 
that it refer to can be called through the named dispatcher and the 
context attributes and config params in the BlockContext can be 
configured in the Spring configuration for the BlockServlet. Instead of 
using the named dispatcher a special block protocol can be used.

The BlockServlet can be considered as a minimal webapp container and 
inside it a servlet as e.g. the SitemapServlet can be executed. The 
cocoon-blocks-fw module also contain mechanisms for polymorphic 
BlockServlet inheritance and for rewriting block protocol URIs to 
absolute URIs.

> This terminology overloading is kind of confusing even to me, and I'm 
> not really a newbie anymore... is there a plan to resolve the 
> nomenclature issue?

As you can see there was a quite gradual divergence from the original 
concept to what we have today. IMO it would be preferable to just use 
the word "block" in one of the two uses of the the word.

As we have used the term block for the container aspect for so long we 
probably have keep that (although "plugin" probably would be easier to 
understand for outsiders).

It would probably be better to find some other terminology that not use 
the word "block" as prefix for the polymorphic servlet service 
infrastructure in the cocoon-blocks-fw.

Observe however that the terminology still is unambiguous while 
unnecessary confusing:

block - a container containing classes, resources and services

block servlet, block context, block protocol - participants in the 
servlet service infrastructure.

>  Or is the intent that all of today's "blocks" will 
> someday become "Blocks", or what?

No, blocks will continue to be containers, although more sophisticated such.


So what do you/others think? Is it still possible to improve the 
terminology? Should we do it? And what terminology should we use instead 
in such a case?


View raw message