cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
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 [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.
>

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

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

>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

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




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


Mime
View raw message