Return-Path: 
 <dev-return-50080-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 50099 invoked from network); 24 Oct 2003 14:50:05 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 24 Oct 2003 14:50:05 -0000
Received: (qmail 88423 invoked by uid 500); 24 Oct 2003 14:49:56 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 88139 invoked by uid 500); 24 Oct 2003 14:49:53 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 88108 invoked from network); 24 Oct 2003 14:49:53 -0000
Received: from unknown (HELO linux.local) (80.116.68.72)
  by daedalus.apache.org with SMTP; 24 Oct 2003 14:49:53 -0000
Received: from apache.org (localhost [127.0.0.1])
	by linux.local (Postfix) with ESMTP
	id 97CB584D40; Fri, 24 Oct 2003 16:49:51 +0200 (CEST)
Message-ID: <3F993C0E.3080200@apache.org>
Date: Fri, 24 Oct 2003 16:49:50 +0200
From: Gianugo Rabellino <gianugo@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lenya Developers List <lenya-dev@cocoon.apache.org>,
	dev@cocoon.apache.org
Subject: [RT] Sitemap inheritance (was: User Pipeline Customization)
References: <bnavrg$1ns$1@sea.gmane.org> <3F992447.2050004@wyona.com>
 <bnb927$lqf$1@sea.gmane.org> <bnbb2u$qhb$1@sea.gmane.org>
 <bnbc0h$sok$1@sea.gmane.org>
In-Reply-To: <bnbc0h$sok$1@sea.gmane.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N


I'll take this lenya-dev post from Andreas as a starting point, since 
this is a blatant case of "shared neurons": I was thinking about exactly 
the same things this morning on a conversation with Ricardo, and the 
more I think about it, the more I tend to realize that it would boost 
Cocoon productivity even more.

> I could also imagine something like "sitemap inheritance".
> I guess in this case the inheriting sitemaps would have to
> be known at compile-time and the corresponding pipelines
> would have to be replaced. But I'm not aware of all the
> consequences of such a concept.

I have been quite uncomfortable at times with Cocoon management of large 
applications. I was unable to realize exactly why I had some alarms off 
scale, until a while ago, when I started thinking on how difficult is to 
reuse sitemap logic across applications.

What happens to me quite often is that I'm constantly doing c&p from 
sitemaps, trying to reuse existing snippets all over the place. This is 
of course the poorest man's reuse technique, something I learnt should 
be avoided at all costs.

So far, Cocoon has a few ways to "abstract" and "reuse" existing 
pipelines: the "resource" concept and the cocoon protocol. Both, 
however, are a bit clumsy and verbose. The resource bit has been so much 
abused lately that the need for "virtual components" became pretty clear 
(and indeed virtual components will be a huge help). The cocoon protocol 
is somehow cleaner, but still requires long and error-prone copy & paste 
operations.

Let's see a use case as an example, and take the simplest one, a 
pipeline rendering xml, html or PDF depending on the URI extension, 
included in the "simple.xmap" sitemap:


<pipeline>
    <match pattern="*.xml">
       <g type="file" src="{1}.xml/>
       <s/>
     </match>

    <match pattern="*.html">
       <g type="file" src="{1}.xml/>
       <t src="xml2html.xsl"/>
       <s type="html"/>
     </match>

    <match pattern="*.pdf">
       <g type="file" src="{1}.xml/>
       <t src="xml2fo.xsl"/>
       <s type="fo2pdf"/>
     </match>
</pipeline>


Suppose we have to build another Cocoon application, with a sitemap that 
has to produce all the above outputs _plus_ excel files. If we had 
sitemap inheritance (read: overriding) we could have just done:

<sitemap extends="simple.xmap">
[...]
   <pipeline>
     <!-- Newly added case -->
    <match pattern="*.xls">
       <g type="file" src="{1}.xml/>
       <t src="xml2gnumeric.xsl"/>
       <s type="poi"/>
     </match>
   </pipeline>
</sitemap>

The same goes for overriding. Suppose that the html transformation, in 
this new pipeline, requires skinning. With overriding it would be as 
simple as:

<sitemap extends="simple.xmap">
[...]
  <pipeline>
    <!-- Overridden HTML generation -->
    <match pattern="*.html">
       <g type="file" src="{1}.xml/>
       <t src="xml2html.xsl"/>
       <t src="skin.xsl"/>
       <s type="poi"/>
     </match>
   </pipeline>
</sitemap>

Here, reuse would be promoted as its best, without a need for 
resource-exists hacks and with a much cleaner, object oriented, sitemap 
design in mind.

Of course all this opens an interesting can of worms:

1. unlike classes, pipeline ordering in the sitemap is important (so 
it's not easy to decide where an added pipeline should go). This could 
be a showstopper;

2. resource resolving can be messy: should source resolution be 
performed in the parent sitemap (and context) or in the new one? Both 
have pros and cons: as a generator parameter, it makes sense to resolve 
it in the current context, but most probably the t-s are better served 
if resolved in the parent's context.

3. URI matching might bring quite a few problems too.

The more I think about it, though, the more I feel that this solution 
could be a usability boost for Cocoon. Probably hard to implement (even 
if the components part already does inheritance), but still very useful 
for complex Cocoon applications. And, in any case, even if _this_ is not 
the solution, I think that we should provide a way to have 
understandable and manageable sitemaps for complicated apps.

Does all this make any sense or is it just FS gibberish? :-)

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
     (Now blogging at: http://blogs.cocoondev.org/gianugo/)