Just want to express my solidarity with Rob.
It's been somewhat surprisingly painful experience for me to get Cocoon
running and consequently to get my own demos running. I am also a believer,
from experience, in building small pieces at a time. Just big enough to have
value on their own and small enough for everyone to understand and embrace.
In my experience, the big and nice things have been built over multiple
iterations, not at once.
If it counts, I vote for a first iteration of Cocoon blocks where one can
drop a .cob file and swtich to the browser.
Maybe by the time this iteration is ready, Cocoon will have a more
sophisticate validation infrastructure which could be leveraged.
Ivelin
----- Original Message -----
From: "Rob Jellinghaus" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 29, 2002 1:07 PM
Subject: Cocoon Blocks and contract validation
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
