cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hartle <>
Subject Re: [RT] Cocoon web applications
Date Fri, 05 Oct 2001 12:41:55 GMT

I guess that adding practical examples and consequences to the 
suggestions will help discussing the concepts at a broader scale. I just 
love examples that can be torn in half and rebuild.

Ok, asbestos underwear in position - here we go:

1.) We want easily deployable packages, just like .war or .ear files in 
other contexts. For Cocoon, this would be .cwa files; I guess it's just 
a zip file with some information relating to the package, like a 
MANIFEST in a .jar file. I would consider this extra information to be 
at least a sitemap.xmap that controls the sub-URI-space of the package.

2.) We want these easily deployable .cwa packages to be self-contained. 
I consider modifying a package for setup issues impractical, so the 
setup for a package should happen outside of the package. Inversion of 
control, Avalon principle ;). At the same time this allows a single .cwa 
package file to be setup and deployed at multiple places at the same time.

Some setup like mounting could happen in a sitemap.xmap, as currently 
this is the place controlling URI space; this even allows for an 
auto-mounting extension for the sitemap. Many packages will require 
setup beyond mounting, for example where to find the corporate identity 
stylesheets, which accounting database to use, or what's the business 
name to be put on the tax report thats being produced, so I need both 
the information about what I CAN configure and what I actually DO 
configure for this package.

I think of the former as sort of a standardized setup-info.xml or the 
like regulary contained in .cwa packages that have something to be 
configured. The latter could be an configuration file positioned 
somewhere near the sitemap.xmap and cocoon.xconf files in the 
filesystem. One might even refer to the configuration file from the 
sitemap, so the way the configuration files are being organized is left 
as a choice to the system administrator.

3.) As the .cwa package does not know in advance where it will be 
deployed, it cannot know about the URI space it will be accessable from 
via the web, yet most content needs to point to other content in this 
package, for example just simple links from HTML page A to HTML page B. 
If  resource names of pipelines were added to the sitemap which are 
local to the package/sitemap, the .cwa designer could just use resource 
names in his package and have them resolved later via taglibs in a page 
or other means in the sitemap like a cocoon-protocol extension like it 
was posted for role-based access.

4.) .cwa packages will rarely be on their own, not interconnecting. So 
resource naming would need to work between .cwa packages. Giving each 
deployed .cwa package a global name, the local resource name for a 
pipeline could be referenced from another position.

I guess there are plenty of opportunities to discuss what can be done 
better or easier differently, so let's hear them.

Best regards,

Michael Hartle

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

View raw message