Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3DA4159A.3030807@apache.org>
Date: Wed, 09 Oct 2002 13:40:10 +0200
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: defaulting to a matcher when another one is not present
References: <GMEBIBHGAOFGJCDPJANDMEKKFGAA.cziegeler@s-und-n.de>
 <1034153270.3da3ed3699cc2@mail.studiocorbellini.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Stefano Mazzocchi wrote:
> Quoting Carsten Ziegeler <cziegeler@s-und-n.de>:
> 
> 
>>
>>>-----Original Message-----
>>>From: Ovidiu Predescu [mailto:ovidiu@apache.org]
>>>Sent: Monday, October 07, 2002 10:59 AM
>>>To: cocoon-dev@xml.apache.org
>>>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.

This makes it a -1 from me too.

>>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.

If the parent sitemap has asked the sub-sitemap to deal the request, why 
on earth would it want to continue doing it itself?

The parent sitemap must decide what to do with the request; we can make 
a SubSitemapHandlableAction that checks if the sub-sitemap can handle 
the request, but it's really a stinky hack that makes subsitemap decide 
on the URI space of the parent, which is a break in the chain of 
responsibility, since it creates a callback.

>>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.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org