cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: defaulting to a matcher when another one is not present
Date Mon, 07 Oct 2002 09:54:47 GMT
Carsten Ziegeler wrote:

>>-----Original Message-----
>>From: Ovidiu Predescu []
>>Sent: Monday, October 07, 2002 10:59 AM
>>Subject: Re: defaulting to a matcher when another one is not present
>>On Sunday, October 6, 2002, at 01:28  AM, Sylvain Wallez wrote:
>>>Ovidiu Predescu wrote:
>>>>I have the following problem. I want to write a <map:match 
>>>>pattern="**.html"> matcher in the top-level sitemap, and have it 
>>>>invoked for most of the HTML page generation. However I'd like this 
>>>>rule to be overwritten in sub-sitemaps, e.g. if a sub-sitemap 
>>>>implements a  rule with a similar pattern, this rule should take 
>>>>precendence. This would be very similar to the precedence rule in 
>>>>XSLT, allowing developers to define catch-all rules, while still 
>>>>permitting the rule to be rewritten.
>>>>Do we have something like this which can implement this behavior?
>>>What if we could "come back" from a <map:mount> to the parent sitemap 
>>>if no pattern matched in the subsitemap ?
>>I think this will do it. Should we vote for extending the semantics of 
>><map:mount> this way?
>>I'm +1.
>Currently I'm -0 but with a tendency to -1.
>Why? I see these reasons:
>1) This is an incompatible change - currently if nothing matches in the 
>   subsitemap, the error handler is invoked and people rely on this, so
>   this will break many installations.

Agree : this behaviour should be explicitely written in the mount. This 
can go through and additionnal attribute such as <map:mount src="sub/" 

The "must-match" (or a better name) attribute tells if the request must 
be handled by the request and defaults to true to ensure backwards 

>2) I think it is more natural if a sub sitemap is invoked that it is 
>   the sole responsibility of this sub sitemap to process the request.

That's true if you consider each subsitemap to be a fully autonomous 
subapplication, but not if you consider the top-level sitemap to be a 
sort of container providing global services to subsitemaps.

Considering also that a parent sitemap already provides components to 
subsitemaps, this doesn't seem so unnatural. Some people also asked 
views to be inherited by subsitemaps, which also goes in this direction.

>3) Before you consider implementing this simple sounding change, have a
>   look at all the component manager and source handling stuff which
>   takes place when a sub sitemap is invoked - it's very difficult
>   to implement your wantet behaviour without breaking everything.

Why is this so difficult ? The environment context is changed when 
mounting a subsitemap. Will it be difficult to restore the context when 
"unmounting" a sitemap ?


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message