cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@apache.org>
Subject [RT] Sitemap inheritance (was: User Pipeline Customization)
Date Fri, 24 Oct 2003 14:49:50 GMT

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/)


Mime
View raw message