Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <1093947144.32172.2070.camel@ighp>
References: <cguiso$kap$1@sea.gmane.org> <41334F2B.7080602@apache.org>
 <Pine.LNX.4.61.0408301919190.8543@lapgp.otego.com>
 <C2B42B79-FADC-11D8-8713-000393B3DE96@hard-bop.com>
 <1093917637.32173.106.camel@ighp>  <ch182b$6e7$1@sea.gmane.org>
 <1093947144.32172.2070.camel@ighp>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <63A7639E-FB5C-11D8-9120-000393539234@pcextremist.com>
Content-Transfer-Encoding: 7bit
From: Miles Elam <miles@pcextremist.com>
Subject: Re: [Proposal] Add pass-through capability to mounted pipelines
Date: Tue, 31 Aug 2004 07:45:23 -0700
To: dev@cocoon.apache.org

Just to add noise to the discussion...  ;-)  This passthrough (or 
whatever it's ultimately called) could also be used to make Cocoon 
installation and first setup easier.

For example, let's say you have your Cocoon installation ready to go on 
the filesystem.  After configuring the servlet container, the next step 
is usually to edit the main sitemap.  This can be daunting for new 
users (it was for me the first few times) as the default sitemap is not 
exactly a five-liner.

But what if you split it off a la Forrest?  In the main sitemap, you 
have all of the basic configurations and component definitions 
(including or excluding based on the block inclusion or exclusion in 
many cases as is the case now with compilation), all of the samples, 
tutorials, documentation, etc.  However, you also have a "pass-through" 
sitemap mount that matches everything going to mysite.xmap (or 
whatever) with a bare, minimal sitemap.  It would be this minimal 
sitemap that folks would start out with and add their matchers to and 
get familiar with the system.

Adding this baby step keeps folks from getting turned away from excess 
complexity (or at least hiding it for a while), allows them to learn 
the basic skills, and when the time comes that they need to edit the 
main sitemap.xmap, they will already have a firm grounding in the basic 
building blocks of how Cocoon works.  It also provides a means for 
people to have their own sitemap without having to make large edits 
when a new Cocoon build is made.  The pipes vs. pipelines change comes 
to mind where I simply tried to copy my customized sitemap onto a new 
build, and (surprise) it failed.  I ended up having to do a line by 
line comparison of the default and customized sitemaps to find the 
problem.  Similar problems have cropped up as components have been 
added/removed/renamed over the years.

If, on the other hand, my customizations were in its own file where I 
could know/assume that the base sitemap was correct (because I copied 
it directly from a build), debugging problems becomes a lot easier.

Currently I have such a setup where the main, default sitemap is kept 
pretty much intact while my changes are simply mounted in a single 
line.  The pass-through proposal makes it possible to do this in the 
general case however.

WDYT?

- Miles Elam