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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
