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