Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3CAB043E.7A6849F9@apache.org>
Date: Wed, 03 Apr 2002 15:31:42 +0200
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Cocoon Blocks and contract validation
References: <5.1.0.14.2.20020329105710.02433390@unrealities.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rob Jellinghaus wrote:
> 
> 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.  

Yes.

> 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.

Hmmm, this would be true if blocks didn't expose polymorphic behavior.
 
> 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 is a good point.

> This minimal Cocoon block mechanism is also a lot easier than the rest of
> it :-)  

What you outline above *cannot* be called 'block' but simply 'package'
since blocks exhibit polymorphic nature unlike 'packages' which are
simply functional archives with a one-2-one relationship with its
contract and its implementation.

So, a minimal 'cocoon packages' mechanism (which clones the Servlet API
WAR concept without extending it to the use of Avalon Blocks) still
requires:

 1) classloading
 2) URI mounting

but I'm *dead sure* that people will soon start asking for 'inter
package' communication ("how do I access this stylesheet from package A
to package B?") and start doing 'hacks' such as absolute file
positioning of resources.

once this is in place and released, we *have* to support it.

This means that by the time we are ready to deploy Cocoon Blocks, people
will have to move things.

> In my strong opinion, this should be the first thing you do, maybe
> even in Cocoon 2.0.5 or something.  

In my *even stronger* opinion, cloning the WAR package concept is a
*very poor* way of dealing with the problems outlined.

Sure, we won't implement 'install-over-the-web' functionalities at
first, but the architecture should start *complete* since incremental
functionality is just too weak and, besides, the *minimal* support is
probably 80% of the code to write, so the remaining 20% can be added
right there with no further delay and the design done coherently in one
big step.

> 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.

I think you don't seem to understand the impact of polymorphism on this.
 
> 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*.

I strongly disagree in this specific case: look at it from a SoC
perspective? you are proposing to separate concerns depending on 'ease
of implementation', which is a *very* dangerous thing to do, expecially
if it refactors the system in such a way that is orthogonally oriented
compared to the whole architecture.

Please, consider that we have to *support* what we build and adding
polymorphism later on might *not* be back compatible.

Anyway, if you have any idea on how to make it 'incremental' and avoid
any possible back-compatibility drawbacks, I'll be all ears :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


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