Return-Path: 
 <cocoon-dev-return-29297-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 17266 invoked by uid 500); 10 Jul 2002 14:40:30 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 17254 invoked from network); 10 Jul 2002 14:40:29 -0000
Message-ID: <3D2C477A.9090306@anyware-tech.com>
Date: Wed, 10 Jul 2002 16:40:58 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0rc2) Gecko/20020510
X-Accept-Language: fr, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [PROPOSAL] Extending Sitemap Error Handling
References: 
 <Pine.LNX.4.43.0207101244150.5098-100000@fztig938.bank.dresdner.net>
 <3D2C2BF9.50907@anyware-tech.com> <3D2C377A.7000605@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Nicola Ken Barozzi wrote:

>
> Sylvain Wallez wrote:
>

<snip/>

>> When an exception occurs, the sitemap engine builds a Notifying 
>> object that is available within the <handle-errors>. This Notifying 
>> has a getType() method which is exactly what we need for this "type" 
>> attribute.
>
>
> There are many other attributes, not only getType.


I know that (went back to the source), but this property seems to me the 
most appropriate for this kind of information.

> I wrongly assumed that it would be a "level" of error.
> We should start giving it a real meaning.


Yes, definitely !

>> But getType() always returns "error" unless your exception implements 
>> Notifying (which none does, and IMO having an exception implement 
>> Notifying to drive sitemap error-handling is mixing concerns).
>
>
> Not really true...


Not really false ? ;-P

>> So we could configure the NotifyingBuilder so that it can associate 
>> exception classes to notifying types.
>>
>> <notifying-builder>
>>  <type name="404" src="org.apache.cocoon.ResourceNotFoundException"/>
>>  <type name="500" src="org.apache.cocoon.ProcessingException"/>
>>  <type name="access-denied" src="java.lang.SecurityException"/>
>>  <type name="my-error-case" src="my.app.someSpecificException"/>
>> </notifying-builder>
>
>
> This I like better... 


Cool :-))

> It basically means that you make the mapping of the exception name to 
> an easy handle...


Yep. And the important point is avoiding to writing exception class 
names in the sitemap.

>> Notice the two first lines that ensure compatibility with what we 
>> have today.
>>
>> And then in the pipelines :
>> <map:handle-errors type="access-denied">
>>  <map:transform src="accessDenied.xsl"/>
>>  <map:serialize/>
>> </map:handle-errors>
>>
>> <map:handle-errors type="my-error-case">
>>  <map:transform src="SpecificError2html.xsl"/>
>>  <map:serialize status-code="500"/>
>> </map:handle-errors>
>>
>> Thoughts ?
>
>
> I would rewrite your case like this:
>
>  <notifying-builder>
>   <type name="404" src="org.apache.cocoon.ResourceNotFoundException"/>
>   <type name="500" src="org.apache.cocoon.ProcessingException"/>
>   <type name="access-denied" src="java.lang.SecurityException"/>
>   <type name="my-error-case" src="my.app.someSpecificException"/>
>  </notifying-builder>
>
>  <map:handle-errors>
>
>   <map:match type="error" pattern="access-denied">
>     <map:transform src="accessDenied.xsl"/>
>     <map:serialize/>
>   <map:match>
>
>   <map:match type="error" pattern="my-error-case">
>     <map:transform src="SpecificError2html.xsl"/>
>     <map:serialize status-code="500"/>
>   <map:match>
>
>   <map:match pattern="*">
>     <map:serialize status-code="500"/>
>   <map:match>
>
>  </map:handle-errors>


Ok. I like this now that we can have a meaningful type on Notifying, and 
agree to deprecate the "type" attribute on handle-errors.
As we say here : "only stupid people don't change their mind" ;)

Minor remark : a selector seems more suitable than a matcher as we will 
most often perform a "switch" on the error type (also shown in your 
example). We can also have both.

> But we could simply do:
>
>  <map:handle-errors>
>
>   <map:match type="error" pattern="access-denied">
>     <map:transform src="accessDenied.xsl"/>
>     <map:serialize/>
>   <map:match>
>
>   <map:match type="exception" pattern="my.app.someSpecificException"> 


I don't like this one as it shows explicit class names outside of 
<map:components>

>     <map:transform src="SpecificError2html.xsl"/>
>     <map:serialize status-code="500"/>
>   <map:match>
>
>   <map:match pattern="*"> 


This match can even be avoided as we're in the fallback when there is no 
match above : it's the "otherwise" part of a selector.

>     <map:serialize status-code="500"/>
>   <map:match>
>
>  </map:handle-errors>
>
>
> Of course, we will need to put a
>
>  <notifying-builder>
>   <type name="404" src="org.apache.cocoon.ResourceNotFoundException"/>
>   <type name="500" src="org.apache.cocoon.ProcessingException"/>
>   <type name="access-denied" src="java.lang.SecurityException"/>
>   <type name="my-error-case" src="my.app.someSpecificException"/>
>  </notifying-builder>
>
> thing in cocoon.xconf to handle the major types of errors, so that the 
> match type="exception" is not used a lot, or even at all.


Wouldn't it be better located in <map:components> ? This would allow 
specific error types to be defined in each sitemap.

> Other thoughts?


Errmm... I still don't like the implicit generator in <handle-errors>...

> Keep calm Stefano, I know you get nervous when Sylvain and I discuss 
> at this speed, but believe me, we are communicating, it's not noise ;-P 


Sure we're communicating ! Why does Stefano get nervous ? Because we 
sometimes communicate loudly ?

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