cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [design] Cocoon Blocks 1.1
Date Sat, 02 Nov 2002 23:08:39 GMT
Stefano Mazzocchi wrote:

>                             Cocoon Blocks
>                             -------------
>   author: Stefano Mazzocchi
>   status: working draft
>   version: 1.1
> (see the end of the document for changes from the previous version)
> DISCLAIMER: This document must be considered as a working draft and 
> may be updated at any time.

OK. Let me throw in some material for version 1.2 ;-)

Throughout this paper, examples show blocks providing "resources" to 
their users (such as stylesheets of images), but the word "service" is 
used several times to identify what is provided by a block, and IMO 
services are more important to define a block contract than resources.

Most of this was already stated after version 1.0, back in July. See

Here is the most relevant part :


>please note the
> block:skin:/stylesheets/site2xhtml.xslt

IMHO, this example goes strongly against the benefits that blocks want 
to bring. The functionnality brought by the 'skin' block is... skinning. 
It's not an XSL stylesheet at a particular location. What if someone has 
written the killer skin for his site, but this skin requires a 
multi-stage pipeline that cannot be represented by a single stylesheet ?

The contract of a block should be services identified by their URI, and 
not files at well-known locations (even if these 'files' are in fact 
produced by a pipeline).

So what about something like :
  <map:call resource="block:skin:/site2xhtml"/>

This call "jumps" to a service provided by the block and its URI is part 
of the block's contract. We don't care (because we don't have to) if the 
service is implemented by an XSL or by the next-generation transformer.

What the "jump" does is feed a pipeline in the block with the result of 
the current pipeline. The whole pipeline is terminated in the called block.

But just as a pipeline can serialize or not depending on if it's an 
internal request or not (see SitemapSource), the same service could be 
used as a transformation. We could then write something like :
  <map:transform type="pipeline" src="block:skin:/site2xhtml"/>
  <map:transform type="urlencoder"/>

By considering blocks as pipeline services, we really achieve true 
polymorphism for blocks, because we totally abstract the way their 
contracts are implemented.

[note that all the above isn't in fact block-specific and can be made 
today inside a single sitemap]


After this we had a long conversation about the semantics to be used to 
identify which part of a pipeline we want the caller to use, which 
unfortunately fell flat because I wasn't able to make you understand my 
thoughts. I'd like someday to have the luck Carsten had recently to meet 
you for real. Too bad the GetTogether is the same week as the ApacheCon :-(

Anyway, let's forget for now these syntactic problems. The important 
thing above is that a block should provide services by means of pipeline 
URIs and not resources.

If we were to compare a block with a Java class (not so silly, since 
blocks now have inheritance), a pipeline service would be a method and a 
resource would be an attribute. Is it good programming practice to 
define a class contract by its attributes ? No, and the same applies to 
blocks, if we want their contracts to be solid enough to accept various 

I have kept below only parts that show the use of services  :


> Improvement #1: component-oriented deployment
> ---------------------------------------------
> Let me give you a possible use-case scenario.
> Let us suppose that we implement WAR-like package deployment on top of 
> Cocoon and that your application requires both PDF serialization and 
> SVG->PNG rasterization.
> Then, you implement another cocoon web application and you still 
> require PDF generation.
> Unfortunatley, since WAR-like installation isolates the packages and 
> their classloaders, you have to install the PDF serialization 
> libraries twice.
> Thus the idea of blocks as units of deployable service. Here is a 
> picture: 

So the main idea of blocks is about services. Great !


> Improvement #2: polymorphic behavior
> ------------------------------------


> Here, the webapp1 requires "fo-pdf" serialization services but it does 
> not care (nor should!) which implementation of this service is 
> actually located into the system.

Sure : the "fo-pdf" _service_ can be implemented by a single serializer, 
or by some transformations preceding another serializer. This clearly 
cannot be a resource.


> Improvement #3: block inheritance
> ---------------------------------


> The best solution is to allow my block to explicitly "extend" that 
> block and inherits the resources that it doesn't contain.

Side note : we must not forget to allow a block to call 
services/resources of its parent block (like a "super" call in Java).


>  +---------------------------+
>  | Part 2: technical details |
>  +---------------------------+


> Resource dereferencing
> ----------------------


> For example, the myblock.cob/sitemap.xmap file could contain a global
> matcher which works like this:
>    <map:match pattern="**/*.html">
>     <map:generate src="{1}.xml"/>
>     <map:transform src="block:skin:/stylesheets/document2html.xslt"/>
>     <map:serialize/>
>    </map:match>
> please note the
>  block:skin:/stylesheets/document2html.xslt 

Here is what triggered this idea of "pipeline services" ! This example 
only shows publication of _resources_ (i.e. static files) by the block !


> ----
>  1) blocks should allow to depend on 'ranges' of behavior versions. 
> Let's try to come up with a way to describe those ranges effectively.

IIRC, there's something in Avalon to handle this.


Ok. I hope this time this notion of "pipeline services" will go further 
and that we will solve the misunderstanding we had 4 months ago...


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

To unsubscribe, e-mail:
For additional commands, email:

View raw message