cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: Cocoon Blocks
Date Thu, 15 Aug 2002 12:45:42 GMT
On Mon, 12 Aug 2002, Leigh Dodds wrote:

> > This was one of the core issues Cocoon Blocks should solve in the end.>
> > Giacomo
> As an irregular member of this list, I keep seeing 'Blocks' being mentioned
> (usually as the solution to all kinds of problems! :)
> Can anyone point me to some documentation, list discussion threads, or
> even scratchpad stuff that describes/demonstrates what Blocks actually
> are?

One major point is that Cocoon scales good from the sitemap point of view
(root-sitemap -> sub-sitemap -> ... -> sub-sitemap) but does not on the
Component level (one single cocoon.xconf). Everybody which ever tried to
integrate a Cocoon application which comes with its own Avalon Components
into an already running Cocoon system knows what I am talking about.
You need to merge those new Components into the cocoon.xconf file for
every new application you'd like to deploy in the same Cocoon system and
this can grow into a maintainance nightmare.

The other point Cocoon Blocks (COB) will solve is modularisation. Consider
the following.

1. There is a COB interface defined about skinning application data
of defined XSchemas (navigations, menues, content) by transformations
(i.e. XSLT) into something else (i.e. HTML)

2. There is a COB interface defined about accessing mail messages which
generates defined XSchemas of mail messages and mail folders from mail
stores like IMAP, POP, mboxes or "write your own"

3. There is a COB which offers an WebMail application which depends on
   - a skinning COB
   - a mail message accessing COB

Now, when someone likes to deploy the WebMailCOB it uses the Cocoon COB
management application which asks for a URI to the COB to deploy. As a COB
will have meta data inside, the management console will be able to ask for
configuration data for the COB and also knows of unresolved dependancies
to other COBs. So the deployer of the WebMailCOB will be asked where the
dependant skin and access COBs are.  Now, the management console could
offer implementations for them from a well known site like
(URL will be configurable of course) which have been registered there. Now
you can select the Christmas skin COB and the IMAP access COB from the
list and configure them to have your WebMail ready and running.

And now you will be free to use other skin COBs in terms of minutes or you
can write your own to achieve "corporate identity". You have your mails
stored in a database and there is no COB for it? Write your own and have
them be served by the WebMailCOB.

So, Cocoon Blocks will not be "the solution to all kinds of problems" as
you might have heared. But it will ease deployment of several "modules"
into one single Cocoon system.

Stefano and I also used the term "naked Cocoon" which sould be a war file
that comes with nothing but what is needed to run the COB management
application. This enables users to start with it and deploy COBs to have
something running by Cocoon.

Hope this and the link Bertrand mentioned in an other mail in this thread
will help understand what Cocoon Blocks should solve.


> I'd like to get this into the Wiki.
> Cheers,
> L.

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

View raw message