cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Jellinghaus <r...@helium.com>
Subject Cocoon Blocks and contract validation
Date Fri, 29 Mar 2002 19:07:54 GMT
Speaking as a Cocoon user with Apache committer credentials (I am a 
committer to xml-axis):

I'm ramping up on Cocoon right now.  As of this moment, the thing that 
makes me most uncomfortable with Cocoon is its lack of modularity at the 
sub-site level.  Installing a new "component" ("sub-sitemap" seems to be 
the closest equivalent in Cocoon 2.0.2) may involve changing cocoon.xconf 
and the top-level sitemap.xmap in various subtle ways (adding 
<builtin-logicsheet> definitions, adding sub-sitemap redirections, et al.).

My goal in building Cocoon components is to make them easy to deploy -- 
whatever I build on my home machine should be trivially installable on 
another Cocoon system.  This need is not met by Cocoon right now.  Consider 
chello -- it should be a single, self-contained, minimal, 
automatically-installable (drop it under cocoon/WEB-INF, or in some 
subdirectory thereof, and it just works) project.  Instead it includes *all 
of Cocoon* because explaining how to install it is so hard as to confuse 
the people who most need it -- Cocoon newbies!

Cocoon blocks, if I understand Stefano's characterization, are intended to 
address this issue.  However, Stefano talks not just about packaging a 
Cocoon "subproduct", but also about fetching dependent components over the 
web, and even about automatic contract validation of Cocoon "subproducts" 
(aka Cocoon blocks).  To me, those latter areas -- fetching dependent 
blocks by URI, defining subproduct interactions, and defining *any* notion 
of contract *at all* -- are layers on top of a more basic and minimal 
packaging layer, which does not yet exist.

Cocoon badly needs a *minimal* definition of Cocoon blocks, defined as "a 
self-contained Cocoon product, containing builtin-logicsheets, sitemaps, 
classes, and anything else that may go into a Cocoon project, installable 
simply by dragging and dropping it into a specific area in a vanilla Cocoon 
installation with no changes to cocoon.xconf or sitemap.xmap."  Until 
Cocoon has this, newbies (I speak from immediate experience!) will continue 
to suffer, and deploying Cocoon projects will be much harder than it should be.

This minimal Cocoon block mechanism is also a lot easier than the rest of 
it :-)  In my strong opinion, this should be the first thing you do, maybe 
even in Cocoon 2.0.5 or something.  Then build the additional layers on top 
of this foundation, while all the book authors, tutorial writers, and 
Cocoon developers get started *using* this very useful mechanism that you 
haven't built yet.

Solve the smallest problem first, guys!  You won't shoot yourselves in the 
foot by doing so, since you need all this minimal mechanism in order to do 
the rest of it *anyway*.

Sincerely,
Rob Jellinghaus
http://www.helium.com


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message