Carsten Ziegeler wrote: > > >>-----Original Message----- >>From: Ovidiu Predescu [mailto:[EMAIL PROTECTED]] >>Sent: Monday, October 07, 2002 10:59 AM >>To: [EMAIL PROTECTED] >>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:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
