Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3DA44512.1000905@apache.org>
Date: Wed, 09 Oct 2002 17:02:42 +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: <601F6322AD71D5118D6C0003472515290660D00C@sjmemexc1.stjude.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Hunsberger, Peter 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.
>>>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?

Usually I never do this, I use composition, not inheritance.

I have never found the need to inherit from a non-abstract class yet, so 
you can understand why I don't see the need.
Invert the selection logic, put it in the parent, not the child.

> Why shouldn't you be able to do
> the same thing with sitemaps? 

Why should you? (see below)

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

Please share them with us.

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