cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Real blocks: some thoughts and questions
Date Thu, 11 Sep 2003 18:11:00 GMT
I've been reading through the most recent block related threads: Cocoon
Blocks 1.1 [1] and Implementing Cocoon Blocks [2]. These two documents
pretty much complement each other, the first mostly focussing on the
blocks itself (not just a package but also inheritence and
polymorphism), the second one more focussing on the block manager and
block deployer. 

What I've written below are partly summaries and partly questions. I'm
posting it here, if anyone can offer clarifications on some of this than
that would be great, and otherwise it'll serve as input for the


The main features that cocoon blocks have that are not in pure packaging
solutions like war's are:
* block dependencies, including polymorphism
* block inheritence

The first I quite understand, the second not so much.

Dependencies between blocks

If I got it right, the only dependencies we got between block are:
 - a block can use a component from another block (either a sitemap
component or a generic Avalon component)
 - a block can call a pipeline described in the sitemap of another
block, using the block: protocol

Some things that would thus explicitely not be possible (at this point)
 - classloading dependencies: a block cannot depend on classes or jars
inside another block
 - resource dependencies: one block cannot directly access files (such
as XSL's) in other blocks
 - other sitemap dependencies: using flows, views or resources from a
sitemap in another block.

One exception is that the yet-to-come virtual sitemap components (or
whatever they're called) could be used across blocks.

Extending blocks (block inheritence)
Reading the Cocoon Blocks 1.1 proposal [1] makes me think that block
inheritance is a file-based thing, i.e. files not found in the extending
block are taken from the extended block. Though in some other post in
the discussion following on it, Stefano writes:

"Here, when a sitemap *extends* another one, it's means of falling back:
the two sitemaps are appended and if no matching happens in the first
one, it falls back on the extended one."

Which implies that the extending is more dynamic, i.e. there exist two
sitemap interpreters at runtime etc.

Other than that I couldn't find much information on block inheritence,
so if anyone can shed more light on it, that would be very welcome.

Component lookup
I'm wondering how component lookup will work. For example, suppose I
have a block where I want to use FOP, i.e. the fo2pdf serializer. I'll
make my block depend on the fop blok (or the more generic role). Now how will using the serializer
work? I assume I won't have to declare it in the map:components section
of my sitemap anymore, since the instances of that serializer will be
managed by the component manager of the fop block. So I'll just be able
to write somewhere:

<map:serialize type="fo2pdf"/>

Now how will the component manager know which of the depended blocks to
ask for this component? Check them one by one? Up to now all component
managers are in a parent-child relationship, but blocks will need to use
components from sibling blocks. Hope my explanation is clear enough.

Hmm, now that I think of it, with the block: protocol there is explicit
block addressing: block:dependencyname:/something. Probably we'll have
something similar for component lookups?

Other various stuff

* I assume the block's sitemaps won't have a parent sitemap, i.e. the
Cocoon root sitemap will not be the parent sitemap for block sitemaps.

* Currently sitemap components are managed by a sitemap component
manager. I assume that with blocks, sitemap components will also have to
be mangeable by the "main" block component managers? I.e. the fop block
won't have to include a sitemap simply to declare the the fo2pdf

That's it for now.


Bruno Dumon                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message