cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [PROPOSAL] Extending Sitemap Error Handling
Date Wed, 10 Jul 2002 15:10:00 GMT

Sylvain Wallez wrote:
> 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.

Agreed.

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

As we say here : "only stupid people don't change their mind"
I changed my mind on this, thanks for making it clear to me.
:-)

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

;-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 :-))

Well, in fact it's the reason I made the builder in the first place, 
only that I wasn't yet sure of how to define it.

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

Ok.

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

Of course.

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

+1

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

Yup. Just to show that selection is not the only way.

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

Dunno, maybe you're right, maybe it's also needed because each block can 
have his.

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

I really don't know what is best here, but I have a proposal that comes 
to me now...

The NotifyingBuilder is something that converts Exceptions and 
Notifyings in xml... basically a Generator!
But with the difference that it imposes you a fixed dtd, and can be used 
also with non-sax sources.

So, what about adding a NotifyingBuilder as a Sitemap Component?

<components>
  ...
  <notifying-builders>
   <notifying-builder name="default"
                      classname="org.apache.xxx.NotifyingBuilder">
    <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>
  </notifying-builders>
</components>

...

   <map:handle-errors>
    <map:match type="error" pattern="access-denied">
      <map:notifying-builder/>
      <map:transform src="accessDenied.xsl"/>
      <map:serialize/>
    </map:match>
   </map:handle-errors>

Just a RT...

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

Guess so, and because we are sooooo much verbooose and fast ;-)

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


Mime
View raw message