Re: [RT] Sitemap inheritance

[Gianugo Rabellino <gi...@apache.org>]

(Note to dev@cocoon: Daniel's reply can be read at
http://article.gmane.org/gmane.comp.cms.lenya.devel/1496)

Daniel Fagerstrom wrote:
> Me to ;)
> 
> I agree about all that you say and have also been through the process of 
> hateing copy & paste style Cocoon app reuse, and foinding out that 
> sitemap inheritance is the way to go.
> 
> Still I think that the resource inheritance part of block inheritance is 
> supposed to be build on some kind of sitemap inheritance, see e.g. the 
> last part of 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106570773018093&w=2 and 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106577595921204&w=2
> "nono, inheritance works as the URI matching level, not at the resource 
> level."
> 
> I got that impression from Stefanos talk at the GT as well.

I might have missed that, but still I think that sitemap inheritance 
does not belong to blocks but rather to the core.

> I think that the semantics of sitemap inheritance could be something 
> like this:
> 
> Say that sitemap2.xmap inherits from sitemap1.xmap, then I think that it 
> should be interpreted as:
> 
> sitemap2.xmap:
> <sitemap>
>  <!-- diverse match clauses that will over ride or extend the inhereted 
> ones -->
> 
>  <match pattern="**">
>    <mount uri-prefix="" src="some-path/sitemap1.xmap"/>
>  </match>
> 
>  <!-- error handling -->
> </sitemap>
> 
> The idea is that everything that all URL:s that are not matched in 
> sitemap2 will be tried in sitemap1. For error handling I think that 
> sitemap2 should be able to "catch" errors from sitemap1 and resend them 
> in a customized way, but I have no clear ideas about the details.

I'm sorry, but I don't like that too much. This should work now (or 
pretty much work), but I don't like the match->delegate idea: it should 
be transparent. Also, there can be ordering issues with side effects (no 
figures yet, but still thinking). Ricardo has been suggesting to borrow 
the xsl "include" and "import" concept (the latter allowing for 
overrides): I think that this might be a better way.

>> 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; 
> 
> 
> The inherited pipeline should IMO be used after everything in the 
> extending pipeline. The main problem IMO is how the extending pipeline 
> should handle errors in the inherited pipeline.

Let me think more about it. I do have a strong feeling that it won't 
just be enough, I hope to come back soon with a few examples.
.
> I still think that this discussion is very relevant for Cocoon use in 
> general and that we should discuss it at cocoon-dev.

This is why I cc'ed dev too, but you missed them in the reply. :-) This 
time I changed the reply-to, so from now on it should end up on dev.

Ciao,

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