cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: defaulting to a matcher when another one is not present
Date Wed, 09 Oct 2002 14:51:18 GMT
>> > >> 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:
For additional commands, email:

View raw message