cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [PROPOSAL] Extending Sitemap Error Handling
Date Wed, 10 Jul 2002 14:40:58 GMT
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


Mime
View raw message