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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
