>> > >> 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. >> 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. >> 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. > > Without considering the technical issues, I still agree with Carsten because of > point 1 and 2. > > Consider it a -1 As was previously pointed out (No Pun Intended), point 1) is wrong. The change doe _not_ have to be incompatible. The new behavior can be added in such a way that it is configurable via a new optional attribute on the sub-sitemap specification. Only if the new parameter is explicitly specified would you get the new behavior. Existing sitemaps would continue to function exactly as they do now. If you think that point 2) is valid, let me ask you; do you ever use inheritance in Java? Do you ever use inheritance where you only want to override part of the behavior of the super class but otherwise let the rest of the processing continue on as normal? Why shouldn't you be able to do the same thing with sitemaps? I can think of many use cases where I might want to parcel out handling of a portion of a site to some other group, but still continue processing a request if the other groups sitemap did not handle it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
