You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Michael Melhem <mi...@fztig938.bank.dresdner.net> on 2002/07/10 13:24:40 UTC
[PROPOSAL] Extending Sitemap Error Handling
Dear Cocoon community,
It seems to me that pipelines can only handle two error cases: Namely error 500 (General Exception) and error 404 (ResourceNotFoundException).
There appears to be no way currently to handle specific errors that might be thrown by pipeline components other than to render a general Error 500 page. Am I mistaken?
For example, it may be the case that a custom built generator could throw custom Exceptions that a developer would like to handle in a specific fashion.
To that end, I propose that pipeline be extendend so that it they can handle X number of errors depending on the amount of <map:handle-errors> defined in the sitemap for that pipeline.
<sitemap>
...
<map:handle-errors type="500">
<map:transform src="stylesheets/error2html.xsl"/>
<map:serialize/>
</map:handle-errors>
<map:handle-errors type="404">
<map:transform src="stylesheets/error2html.xsl"/>
<map:serialize />
</map:handle-errors>
<!-- one more or extra error-handles -->
<map:handle-errors type="someSpecificException">
<-- "type" here could me some sort of short code or the actual
full name of the Exception class? -->
<map:transform src="stylesheets/SpecificError2html.xsl"/>
<map:serialize status-code="500"/>
</map:handle-errors>
etc..
</sitemap>
Does anyone see any problems with this approach? Comments?
Best Regards,
Michael Melhem
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
> Nicola Ken Barozzi wrote:
>
>> Sylvain Wallez wrote:
>>
>
> <snip/>
>
>>>> Wouldnt the ability to have custom handle-errors generators make it
>>>> more likely that the handle-errors pipe would throw the very
>>>> error/exception thats its trying to handle..and wouldnt this cause
>>>> an infinate loop?
>>>
>>> No risk of infinite loops, as exceptions occuring inside a
>>> <handle-errors> aren't processed again by the sitemap. Also, not only
>>> generators can throw exceptions, but also matchers, transformers,
>>> actions, etc. which are allowed in handle-errors.
>>
>> Sylvain, you know what?
>> You're right :-)
>>
>> A generator can fail in handle-errors with no real problem, if not
>> that the error is then processed by the servlet, as with any other
>> failing component in that part of pipeline.
>>
>> The only thing that has to be avoided is redirects.
>>
>> As for having different DTDs, it's not a problem, since users will
>> presumably use the supplied Generator for notifications, and also
>> error handling pipelines are usually very simple.
>>
>> Sylvain, now listen to me.
>> Sit down, and stay calm...
>>
>> <drums rolling...>
>>
>> TADA!
>>
>> I remove my -1 on using custom Generators from handle-errors.
>>
>> Hey, Sylvain, don't faint ;-P
>
> Woohoo ! No, I didn't faint, as I was prepared by the drums !
> ROFL ;)
hehehe
>> Yes, for me it's +0 to enable generators in handle-errors, given that
>> 1 there are no -1s for this (I'm not sure I was the only one)
>
> HEY, SOMEONE ELSE ?
>
>> 2 that redirects are completely banned from handle-errors.
>
> Can be checked.
*must* be checked ;-)
>> 3 that the NotifyingGenerator simply notifies what is given in a
>> well-known and public key of the Context (rather than hidden), that it
>> fails gracefully if not present (outputs an empty notification), and
>> that it's called automatically if not defined (backwards compatibility).
>
> You mean "object model" and not "context", right ?
I'm currently discussing in Avalon and sometimes concepts get more
abstract. For me object model is ok, but let's see what others say about it.
> Currently, the
> NotifyingGenerator throws a ProcessingException if there is no Notifying
> in the object model, and IMO it's wiser than silently generating an
> empty notification. Don't you think so ?
Dunno.
In the doubt, let's leave it as-is... we can always add a parameter to
the Generator to switch behaviour.
> To ensure maximum backward compatibility with the current implicit
> generator, and considering that we deprecate the "type" attribute on
> handle-errors, I propose to require an explicit generator for
> handle-errors _without_ the "type" attribute and keep the current
> implicit generator for handle-errors _with_ this attribute.
>
> The effect is that current sitemaps that have a "type-less"
> handle-errors can be ported by simply adding a type="500". An adequate
> error message will help people to migrate smoothly.
It still requires to change the sitemap...
Dunno, it's the same for me, as long as type is deprecated adeguately
and also the implicit generator is.
For me "adeguately" means that for 2.1 sitemaps should be able to run
without modifications.
>> This way users can use it to just notify things directly from actions
>> if needed, even if they are not errors.
>
>
>
> Yes, this will finally allow a wider usage of the notification stuff.
>
>> After/if you do the change, I will see what can be done to nuke the
>> Builder someway if better (seems so now, just need to check).
>
> Why do you want to nuke it ? We just need to add configuration stuff to
> have some meaningful getType().
Will have to think about it...
Anyway what I mean is that part of the builder concept is not needed now
that we'll have Generators; it is just a helper for the NotifyingGenerator.
> As for doing the change, Vadim reminded us there are some bugs to
> correct, and I still have my paid-work to do :-/ I should have some time
> for Cocoon development by the end of the month and in august.
Me too :-)
I am gonna have some time in August :-)
> So if nobody objects, let's add this to the todo list for 2.1.
+1 :-)
I really think that this will make things easier and cleaner without
drawbacks.
--
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
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
> Sylvain Wallez wrote:
>
<snip/>
>>> Wouldnt the ability to have custom handle-errors generators make it
>>> more likely that the handle-errors pipe would throw the very
>>> error/exception thats its trying to handle..and wouldnt this cause
>>> an infinate loop?
>>
>>
>> No risk of infinite loops, as exceptions occuring inside a
>> <handle-errors> aren't processed again by the sitemap. Also, not only
>> generators can throw exceptions, but also matchers, transformers,
>> actions, etc. which are allowed in handle-errors.
>
>
> Sylvain, you know what?
> You're right :-)
>
> A generator can fail in handle-errors with no real problem, if not
> that the error is then processed by the servlet, as with any other
> failing component in that part of pipeline.
>
> The only thing that has to be avoided is redirects.
>
> As for having different DTDs, it's not a problem, since users will
> presumably use the supplied Generator for notifications, and also
> error handling pipelines are usually very simple.
>
> Sylvain, now listen to me.
> Sit down, and stay calm...
>
> <drums rolling...>
>
> TADA!
>
> I remove my -1 on using custom Generators from handle-errors.
>
> Hey, Sylvain, don't faint ;-P
Woohoo ! No, I didn't faint, as I was prepared by the drums !
ROFL ;)
> Yes, for me it's +0 to enable generators in handle-errors, given that
> 1 there are no -1s for this (I'm not sure I was the only one)
HEY, SOMEONE ELSE ?
> 2 that redirects are completely banned from handle-errors.
Can be checked.
> 3 that the NotifyingGenerator simply notifies what is given in a
> well-known and public key of the Context (rather than hidden), that it
> fails gracefully if not present (outputs an empty notification), and
> that it's called automatically if not defined (backwards compatibility).
You mean "object model" and not "context", right ? Currently, the
NotifyingGenerator throws a ProcessingException if there is no Notifying
in the object model, and IMO it's wiser than silently generating an
empty notification. Don't you think so ?
To ensure maximum backward compatibility with the current implicit
generator, and considering that we deprecate the "type" attribute on
handle-errors, I propose to require an explicit generator for
handle-errors _without_ the "type" attribute and keep the current
implicit generator for handle-errors _with_ this attribute.
The effect is that current sitemaps that have a "type-less"
handle-errors can be ported by simply adding a type="500". An adequate
error message will help people to migrate smoothly.
> This way users can use it to just notify things directly from actions
> if needed, even if they are not errors.
Yes, this will finally allow a wider usage of the notification stuff.
> After/if you do the change, I will see what can be done to nuke the
> Builder someway if better (seems so now, just need to check).
Why do you want to nuke it ? We just need to add configuration stuff to
have some meaningful getType().
As for doing the change, Vadim reminded us there are some bugs to
correct, and I still have my paid-work to do :-/ I should have some time
for Cocoon development bu the end of the month and in august.
So if nobody objects, let's add this to the todo list for 2.1.
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
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
> Michael Melhem wrote:
>
>>> Currently, an implicit <map:generate type="!notifying-generator!"/>
>>> is added as the first statement of <handle-errors> (see
>>> HandleErrorsNode.invoke() in treeprocessor).
>>>
>>> What about making this explicit so we can choose other generators as
>>> well, such as a standard file generator to display for example a nice
>>> "page not found" page using some site-wide stylesheets ?
>>>
>>> <handle-errors>
>>> <match type="error" pattern="not-found">
>>> <generate type="file" src="notfound.xml"/>
>>> <transform src="skin/doc2html.xsl"/>
>>> <serialize/>
>>> </match>
>>> <!-- fallback -->
>>> <generate type="notifying"/>
>>> <transform src="system/error2html.xsl"/>
>>> <serialize/>
>>> </handle-errors>
>>
>> I like the idea of an explicit generator in the handle-errors...but
>> doesnt this open up the sitemap handle-errors block for abuse?
>>
>
> What kind of abuse are you thinking of ?
>
>> Wouldnt the ability to have custom handle-errors generators make it
>> more likely that the handle-errors pipe would throw the very
>> error/exception thats its trying to handle..and wouldnt this cause an
>> infinate loop?
>
> No risk of infinite loops, as exceptions occuring inside a
> <handle-errors> aren't processed again by the sitemap.
>
> Also, not only generators can throw exceptions, but also matchers,
> transformers, actions, etc. which are allowed in handle-errors.
Sylvain, you know what?
You're right :-)
A generator can fail in handle-errors with no real problem, if not that
the error is then processed by the servlet, as with any other failing
component in that part of pipeline.
The only thing that has to be avoided is redirects.
As for having different DTDs, it's not a problem, since users will
presumably use the supplied Generator for notifications, and also error
handling pipelines are usually very simple.
Sylvain, now listen to me.
Sit down, and stay calm...
<drums rolling...>
TADA!
I remove my -1 on using custom Generators from handle-errors.
Hey, Sylvain, don't faint ;-P
Yes, for me it's +0 to enable generators in handle-errors, given that
1 there are no -1s for this (I'm not sure I was the only one)
2 that redirects are completely banned from handle-errors.
3 that the NotifyingGenerator simply notifies what is given in a
well-known and public key of the Context (rather than hidden), that it
fails gracefully if not present (outputs an empty notification), and
that it's called automatically if not defined (backwards compatibility).
This way users can use it to just notify things directly from
actions if needed, even if they are not errors.
After/if you do the change, I will see what can be done to nuke the
Builder someway if better (seems so now, just need to check).
:-)
--
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
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Michael Melhem wrote:
>>Currently, an implicit <map:generate type="!notifying-generator!"/> is
>>added as the first statement of <handle-errors> (see
>>HandleErrorsNode.invoke() in treeprocessor).
>>
>>What about making this explicit so we can choose other generators as
>>well, such as a standard file generator to display for example a nice
>>"page not found" page using some site-wide stylesheets ?
>>
>><handle-errors>
>> <match type="error" pattern="not-found">
>> <generate type="file" src="notfound.xml"/>
>> <transform src="skin/doc2html.xsl"/>
>> <serialize/>
>> </match>
>> <!-- fallback -->
>> <generate type="notifying"/>
>> <transform src="system/error2html.xsl"/>
>> <serialize/>
>></handle-errors>
>>
>>
>
>I like the idea of an explicit generator in the handle-errors...but doesnt this open up the sitemap handle-errors block for abuse?
>
>
What kind of abuse are you thinking of ?
>Wouldnt the ability to have custom handle-errors generators make it more likely that the handle-errors pipe would throw the very error/exception thats its trying to handle..and wouldnt this cause an infinate loop?
>
>
No risk of infinite loops, as exceptions occuring inside a
<handle-errors> aren't processed again by the sitemap.
Also, not only generators can throw exceptions, but also matchers,
transformers, actions, etc. which are allowed in handle-errors.
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
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Giacomo Pati wrote:
> On Mon, 15 Jul 2002, Sylvain Wallez wrote:
>
>>Giacomo Pati wrote:
>>
>>>On Wed, 10 Jul 2002, Michael Melhem wrote:
>>>
>>>
>>>>>Currently, an implicit <map:generate type="!notifying-generator!"/> is
>>>>>added as the first statement of <handle-errors> (see
>>>>>HandleErrorsNode.invoke() in treeprocessor).
>>>>>
>>>>>What about making this explicit so we can choose other generators as
>>>>>well, such as a standard file generator to display for example a nice
>>>>>"page not found" page using some site-wide stylesheets ?
>>>>>
>>>>><handle-errors>
>>>>><match type="error" pattern="not-found">
>>>>> <generate type="file" src="notfound.xml"/>
>>>>> <transform src="skin/doc2html.xsl"/>
>>>>> <serialize/>
>>>>></match>
>>>>><!-- fallback -->
>>>>><generate type="notifying"/>
>>>>><transform src="system/error2html.xsl"/>
>>>>><serialize/>
>>>>></handle-errors>
>>>>>
>>>>>
>>>>I like the idea of an explicit generator in the handle-errors...but
>>>>doesnt this open up the sitemap handle-errors block for abuse?
>>>
>>>Oh god, this discussion is old as hell.
>>>
>>>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=96942814002458&w=2
>>>
>>
>>Well, if this discussion comes again after so much time, isn't it
>>because the problem is still there ?
>
> I'm not saying the discussion is useless. Just that it was held since
> years (almost ;).
Yeah, it was the first thing I did in alpha 1 or 2 ;-)
>>As stated in the post you refer to, "you only need one way to XML-ize
>>error information". This proposal doesn't break this, but allows people
>>to generate *something else* when the error-handler doesn't display the
>>error itself, as shown by "notfound.xml" above.
>
> I know. The dangerous part is pointing to the implicit generator used
> ("!notifying-generator!") which is unfortunately wrong named and should be
> something like "<notifying-generator>" to prevent it being explicitely
> used ("<" are illegal characters for attributes).
Making it explicit will remove this problem.
But I agree, for backward compat we should keep the implicit one working
(albeit with a note in the output).
So +1 from me to change the implicit generator name to
<deprecated-implicit-notifying-generator> or similar.
--
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
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Giacomo Pati <gi...@apache.org>.
On Mon, 15 Jul 2002, Sylvain Wallez wrote:
> Giacomo Pati wrote:
>
> >On Wed, 10 Jul 2002, Michael Melhem wrote:
> >
> >
> >
> >>>Currently, an implicit <map:generate type="!notifying-generator!"/> is
> >>>added as the first statement of <handle-errors> (see
> >>>HandleErrorsNode.invoke() in treeprocessor).
> >>>
> >>>What about making this explicit so we can choose other generators as
> >>>well, such as a standard file generator to display for example a nice
> >>>"page not found" page using some site-wide stylesheets ?
> >>>
> >>><handle-errors>
> >>> <match type="error" pattern="not-found">
> >>> <generate type="file" src="notfound.xml"/>
> >>> <transform src="skin/doc2html.xsl"/>
> >>> <serialize/>
> >>> </match>
> >>> <!-- fallback -->
> >>> <generate type="notifying"/>
> >>> <transform src="system/error2html.xsl"/>
> >>> <serialize/>
> >>></handle-errors>
> >>>
> >>>
> >>I like the idea of an explicit generator in the handle-errors...but
> >>doesnt this open up the sitemap handle-errors block for abuse?
> >>
> >>
> >
> >Oh god, this discussion is old as hell.
> >
> >http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=96942814002458&w=2
> >
> >
>
> Well, if this discussion comes again after so much time, isn't it
> because the problem is still there ?
I'm not saying the discussion is useless. Just that it was held since
years (almost ;).
> As stated in the post you refer to, "you only need one way to XML-ize
> error information". This proposal doesn't break this, but allows people
> to generate *something else* when the error-handler doesn't display the
> error itself, as shown by "notfound.xml" above.
I know. The dangerous part is pointing to the implicit generator used
("!notifying-generator!") which is unfortunately wrong named and should be
something like "<notifying-generator>" to prevent it being explicitely
used ("<" are illegal characters for attributes).
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Giacomo Pati wrote:
>On Wed, 10 Jul 2002, Michael Melhem wrote:
>
>
>
>>>Currently, an implicit <map:generate type="!notifying-generator!"/> is
>>>added as the first statement of <handle-errors> (see
>>>HandleErrorsNode.invoke() in treeprocessor).
>>>
>>>What about making this explicit so we can choose other generators as
>>>well, such as a standard file generator to display for example a nice
>>>"page not found" page using some site-wide stylesheets ?
>>>
>>><handle-errors>
>>> <match type="error" pattern="not-found">
>>> <generate type="file" src="notfound.xml"/>
>>> <transform src="skin/doc2html.xsl"/>
>>> <serialize/>
>>> </match>
>>> <!-- fallback -->
>>> <generate type="notifying"/>
>>> <transform src="system/error2html.xsl"/>
>>> <serialize/>
>>></handle-errors>
>>>
>>>
>>I like the idea of an explicit generator in the handle-errors...but
>>doesnt this open up the sitemap handle-errors block for abuse?
>>
>>
>
>Oh god, this discussion is old as hell.
>
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=96942814002458&w=2
>
>
Well, if this discussion comes again after so much time, isn't it
because the problem is still there ?
As stated in the post you refer to, "you only need one way to XML-ize
error information". This proposal doesn't break this, but allows people
to generate *something else* when the error-handler doesn't display the
error itself, as shown by "notfound.xml" above.
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
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Giacomo Pati <gi...@apache.org>.
On Wed, 10 Jul 2002, Michael Melhem wrote:
> > Currently, an implicit <map:generate type="!notifying-generator!"/> is
> > added as the first statement of <handle-errors> (see
> > HandleErrorsNode.invoke() in treeprocessor).
> >
> > What about making this explicit so we can choose other generators as
> > well, such as a standard file generator to display for example a nice
> > "page not found" page using some site-wide stylesheets ?
> >
> > <handle-errors>
> > <match type="error" pattern="not-found">
> > <generate type="file" src="notfound.xml"/>
> > <transform src="skin/doc2html.xsl"/>
> > <serialize/>
> > </match>
> > <!-- fallback -->
> > <generate type="notifying"/>
> > <transform src="system/error2html.xsl"/>
> > <serialize/>
> > </handle-errors>
>
> I like the idea of an explicit generator in the handle-errors...but
> doesnt this open up the sitemap handle-errors block for abuse?
Oh god, this discussion is old as hell.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=96942814002458&w=2
> Wouldnt the ability to have custom handle-errors generators make it more
> likely that the handle-errors pipe would throw the very error/exception
> thats its trying to handle..and wouldnt this cause an infinate loop?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
> Currently, an implicit <map:generate type="!notifying-generator!"/> is
> added as the first statement of <handle-errors> (see
> HandleErrorsNode.invoke() in treeprocessor).
>
> What about making this explicit so we can choose other generators as
> well, such as a standard file generator to display for example a nice
> "page not found" page using some site-wide stylesheets ?
>
> <handle-errors>
> <match type="error" pattern="not-found">
> <generate type="file" src="notfound.xml"/>
> <transform src="skin/doc2html.xsl"/>
> <serialize/>
> </match>
> <!-- fallback -->
> <generate type="notifying"/>
> <transform src="system/error2html.xsl"/>
> <serialize/>
> </handle-errors>
I like the idea of an explicit generator in the handle-errors...but doesnt this open up the sitemap handle-errors block for abuse?
Wouldnt the ability to have custom handle-errors generators make it more likely that the handle-errors pipe would throw the very error/exception thats its trying to handle..and wouldnt this cause an infinate loop?
Regards,
Michael Melhem
>
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>
> Sylvain Wallez wrote:
>
>>> 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...
... that I don't like much : you're proposing a new type of sitemap
component, when we already have the NotifyingGenerator, which basically
wraps Notifier (this one is producing the XML using static methods, and
not NotifyingBuilder).
Currently, an implicit <map:generate type="!notifying-generator!"/> is
added as the first statement of <handle-errors> (see
HandleErrorsNode.invoke() in treeprocessor).
What about making this explicit so we can choose other generators as
well, such as a standard file generator to display for example a nice
"page not found" page using some site-wide stylesheets ?
<handle-errors>
<match type="error" pattern="not-found">
<generate type="file" src="notfound.xml"/>
<transform src="skin/doc2html.xsl"/>
<serialize/>
</match>
<!-- fallback -->
<generate type="notifying"/>
<transform src="system/error2html.xsl"/>
<serialize/>
</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 ?
>
>
> Guess so, and because we are sooooo much verbooose and fast ;-)
>
Yes, and I'm sooooo late on my urgent paid-work because of this ;-)
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
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
RE: [PROPOSAL] Extending Sitemap Error Handling
Posted by Per Kreipke <pe...@onclave.com>.
Nicola wrote:
> > Will whatever the new syntax is allow something like this?
> >
> > <!-- Symbolic only, actual syntax may vary -->
> > <map:handle-errors exception="org.foo.com.RedirectException">
> > <!-- RedirectException puts destURL in the sitemap parameters -->
> > <map:redirect-to href="{destURL}" />
> > </map:handle-errors>
> >
> > That's be nice, then I could actually redirect from generators (and even
> > transformers, etc).
>
> Exactly what I want to prohibit.
>
> Error handling should *not* redirect or create loops.
> If it's part of the flow, use an Action to tell it to the next
> components, not exceptions, which are... exceptional ;-)
What about the site developer who doesn't know Java but understands XML and
XSL? Or even a bit of XSP with the great taglibs we've got but doesn't know
enough to code an Action in Java.
[Assume for a second the database actions aren't good enough because we
don't allow direct DB access from the Cocoon layer]
> Redirecting is generally not needed, and Cocoon was made so to not make
> erdirects part of the necessary flow.
This is the basic part of C2 I don't understand. Given a form that posts to
a different URL, how do you get back to the form page (or a summary page)?
Like this?
<match "form">
<generate>
<transform>
<serialize>
</match>
<match "POST">
<act "doMyPost">
<redirect-to "form-or-summary">
</act>
<generate "form again with errors">
<!-- Does this mean form is in sitemap in two places? -->
...
</match>
I find that difficult conceptually and haven't even gotten it working.
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Per Kreipke wrote:
> Will whatever the new syntax is allow something like this?
>
> <!-- Symbolic only, actual syntax may vary -->
> <map:handle-errors exception="org.foo.com.RedirectException">
> <!-- RedirectException puts destURL in the sitemap parameters -->
> <map:redirect-to href="{destURL}" />
> </map:handle-errors>
>
> That's be nice, then I could actually redirect from generators (and even
> transformers, etc).
Exactly what I want to prohibit.
Error handling should *not* redirect or create loops.
If it's part of the flow, use an Action to tell it to the next
components, not exceptions, which are... exceptional ;-)
Redirecting is generally not needed, and Cocoon was made so to not make
erdirects part of the necessary flow.
--
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
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Per Kreipke wrote:
>Will whatever the new syntax is allow something like this?
>
><!-- Symbolic only, actual syntax may vary -->
><map:handle-errors exception="org.foo.com.RedirectException">
> <!-- RedirectException puts destURL in the sitemap parameters -->
> <map:redirect-to href="{destURL}" />
></map:handle-errors>
>
>
Yes, and it already can.
>That's be nice, then I could actually redirect from generators (and even
>transformers, etc).
>
>
Mmhhh... be very careful with that : Cocoon uses pipelining, and so some
data can be sent to the client browser *before* the generator (or any
other pipeline component) has finished its job.
This means that when you fall into the error handler, redirect may not
work because a partial response has already been sent.
--
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
RE: [PROPOSAL] Extending Sitemap Error Handling
Posted by Per Kreipke <pe...@onclave.com>.
Will whatever the new syntax is allow something like this?
<!-- Symbolic only, actual syntax may vary -->
<map:handle-errors exception="org.foo.com.RedirectException">
<!-- RedirectException puts destURL in the sitemap parameters -->
<map:redirect-to href="{destURL}" />
</map:handle-errors>
That's be nice, then I could actually redirect from generators (and even
transformers, etc).
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Extending Sitemap Error Handling
Posted by Artur Bialecki <ar...@digitalfairway.com>.
To add my 2 cents from user perpective
(without knowing anything about sitemap error hadling)
1. Having mapping to exception name might not me enough. Exceptions
thrown in EJBs are often wrapped in RemoteException, also custom
Exceptions might be of the same type but have different id.
I guess I would need a custom error matcher/selector ?
2. Going to different url (pipe) on given error should be possible.
I guess this will only work for actions and generators (before
any data is sent back)
3. All original request/session/sitemap params should be avaiable to
the error pipe so I can do both PageA --> PageA (with errors/original data),
PageA --> error page (with errors) --> PageA (with original data)
4. One should be able set new params.
5. Exception type and message should be available as parameters.
I'm sorry if some of these are already implemented, impossible, or obvious.
Thanks,
Artur...
> -----Original Message-----
> From: Michael Melhem [mailto:michaelm@fztig938.bank.dresdner.net]
> Sent: Wednesday, July 10, 2002 10:46 AM
> To: cocoon-dev@xml.apache.org; nicolaken@apache.org
> Subject: Re: [PROPOSAL] Extending Sitemap Error Handling
>
>
> On Wed, Jul 10, 2002 at 03:32:42PM +0200, Nicola Ken Barozzi wrote:
> >
> > Sylvain Wallez wrote:
> > >Michael Melhem wrote:
> > >
> > >>Dear Cocoon community,
> > >>
> > >>It seems to me that pipelines can only handle two error cases: Namely
> > >>error 500 (General Exception) and error 404 (ResourceNotFoundException).
> > >>
> > >>There appears to be no way currently to handle specific errors that
> > >>might be thrown by pipeline components other than to render a general
> > >>Error 500 page. Am I mistaken?
> > >>
> > >>For example, it may be the case that a custom built generator could
> > >>throw custom Exceptions that a developer would like to handle in a
> > >>specific fashion.
> > >>
> > >>To that end, I propose that pipeline be extendend so that it they can
> > >>handle X number of errors depending on the amount of
> > >><map:handle-errors> defined in the sitemap for that pipeline.
> > >>
> > >><sitemap>
> > >> ...
> > >>
> > >> <map:handle-errors type="500">
> > >> <map:transform src="stylesheets/error2html.xsl"/>
> > >> <map:serialize/>
> > >> </map:handle-errors>
> > >>
> > >> <map:handle-errors type="404">
> > >> <map:transform src="stylesheets/error2html.xsl"/>
> > >> <map:serialize />
> > >> </map:handle-errors>
> > >>
> > >> <!-- one more or extra error-handles -->
> > >> <map:handle-errors type="someSpecificException">
> > >> <-- "type" here could me some sort of short code or the actual
> > >> full name of the Exception class? -->
> > >> <map:transform src="stylesheets/SpecificError2html.xsl"/>
> > >> <map:serialize status-code="500"/>
> > >> </map:handle-errors>
> > >>
> > >> etc..
> > >></sitemap>
> > >>
> > >>Does anyone see any problems with this approach? Comments?
> > >>
> > >>
> > >
> > >I like this, and proposed something similar back in december (see
> > >http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100739814405987&w=2)
> > >
> > >It didn't had much acceptance at that time both because it involved
> > >class names in the pipelines and because Nicola Ken was refactoring
> > >error notification ;)
> >
> > And because it isn't strictly needed ;-)
> >
> > >But I still would like to have something like this, as I think having to
> > >write a <handle-errors type="500"> and then using a <map:select> to
> > >select depending on the error type is counter-intuitive.
> >
> > no, you would have a <handle-errors>, we decided that type="" would be
> > deprecated, since it's redundant.
> >
> > >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 wrongly assumed that it would be a "level" of error.
> > We should start giving it a real meaning.
> >
> > >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...
> >
> > > 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...
> > It basically means that you make the mapping of the exception name to an
> > easy handle...
> >
> > >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>
> >
> > 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">
> > <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>
>
> Matching for exception types within the handle-errors block - This I
> like! Because (can I start a sentence with "beacuse"?..hmm) the whole point is to make sure that exceptions can be easly
> and intuitively handled depending on error type.
>
> Regards
> Michael Melhem
> >
> >
> > 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.
> >
> > Other thoughts?
> >
> > 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
> >
> > --
> > 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
On Wed, Jul 10, 2002 at 03:32:42PM +0200, Nicola Ken Barozzi wrote:
>
> Sylvain Wallez wrote:
> >Michael Melhem wrote:
> >
> >>Dear Cocoon community,
> >>
> >>It seems to me that pipelines can only handle two error cases: Namely
> >>error 500 (General Exception) and error 404 (ResourceNotFoundException).
> >>
> >>There appears to be no way currently to handle specific errors that
> >>might be thrown by pipeline components other than to render a general
> >>Error 500 page. Am I mistaken?
> >>
> >>For example, it may be the case that a custom built generator could
> >>throw custom Exceptions that a developer would like to handle in a
> >>specific fashion.
> >>
> >>To that end, I propose that pipeline be extendend so that it they can
> >>handle X number of errors depending on the amount of
> >><map:handle-errors> defined in the sitemap for that pipeline.
> >>
> >><sitemap>
> >> ...
> >>
> >> <map:handle-errors type="500">
> >> <map:transform src="stylesheets/error2html.xsl"/>
> >> <map:serialize/>
> >> </map:handle-errors>
> >>
> >> <map:handle-errors type="404">
> >> <map:transform src="stylesheets/error2html.xsl"/>
> >> <map:serialize />
> >> </map:handle-errors>
> >>
> >> <!-- one more or extra error-handles -->
> >> <map:handle-errors type="someSpecificException">
> >> <-- "type" here could me some sort of short code or the actual
> >> full name of the Exception class? -->
> >> <map:transform src="stylesheets/SpecificError2html.xsl"/>
> >> <map:serialize status-code="500"/>
> >> </map:handle-errors>
> >>
> >> etc..
> >></sitemap>
> >>
> >>Does anyone see any problems with this approach? Comments?
> >>
> >>
> >
> >I like this, and proposed something similar back in december (see
> >http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100739814405987&w=2)
> >
> >It didn't had much acceptance at that time both because it involved
> >class names in the pipelines and because Nicola Ken was refactoring
> >error notification ;)
>
> And because it isn't strictly needed ;-)
>
> >But I still would like to have something like this, as I think having to
> >write a <handle-errors type="500"> and then using a <map:select> to
> >select depending on the error type is counter-intuitive.
>
> no, you would have a <handle-errors>, we decided that type="" would be
> deprecated, since it's redundant.
>
> >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 wrongly assumed that it would be a "level" of error.
> We should start giving it a real meaning.
>
> >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...
>
> > 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...
> It basically means that you make the mapping of the exception name to an
> easy handle...
>
> >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>
>
> 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">
> <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>
Matching for exception types within the handle-errors block - This I
like! Because (can I start a sentence with "beacuse"?..hmm) the whole point is to make sure that exceptions can be easly and intuitively handled depending on error type.
Regards
Michael Melhem
>
>
> 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.
>
> Other thoughts?
>
> 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
>
> --
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
> Michael Melhem wrote:
>
>> Dear Cocoon community,
>>
>> It seems to me that pipelines can only handle two error cases: Namely
>> error 500 (General Exception) and error 404 (ResourceNotFoundException).
>>
>> There appears to be no way currently to handle specific errors that
>> might be thrown by pipeline components other than to render a general
>> Error 500 page. Am I mistaken?
>>
>> For example, it may be the case that a custom built generator could
>> throw custom Exceptions that a developer would like to handle in a
>> specific fashion.
>>
>> To that end, I propose that pipeline be extendend so that it they can
>> handle X number of errors depending on the amount of
>> <map:handle-errors> defined in the sitemap for that pipeline.
>>
>> <sitemap>
>> ...
>>
>> <map:handle-errors type="500">
>> <map:transform src="stylesheets/error2html.xsl"/>
>> <map:serialize/>
>> </map:handle-errors>
>>
>> <map:handle-errors type="404">
>> <map:transform src="stylesheets/error2html.xsl"/>
>> <map:serialize />
>> </map:handle-errors>
>>
>> <!-- one more or extra error-handles -->
>> <map:handle-errors type="someSpecificException">
>> <-- "type" here could me some sort of short code or the actual
>> full name of the Exception class? -->
>> <map:transform src="stylesheets/SpecificError2html.xsl"/>
>> <map:serialize status-code="500"/>
>> </map:handle-errors>
>>
>> etc..
>> </sitemap>
>>
>> Does anyone see any problems with this approach? Comments?
>>
>>
>
> I like this, and proposed something similar back in december (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100739814405987&w=2)
>
> It didn't had much acceptance at that time both because it involved
> class names in the pipelines and because Nicola Ken was refactoring
> error notification ;)
And because it isn't strictly needed ;-)
> But I still would like to have something like this, as I think having to
> write a <handle-errors type="500"> and then using a <map:select> to
> select depending on the error type is counter-intuitive.
no, you would have a <handle-errors>, we decided that type="" would be
deprecated, since it's redundant.
> 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 wrongly assumed that it would be a "level" of error.
We should start giving it a real meaning.
> 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...
> 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...
It basically means that you make the mapping of the exception name to an
easy handle...
> 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>
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">
<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>
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.
Other thoughts?
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
--
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
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Michael Melhem wrote:
> Even independent of implementation detail,
> like the idea of having seperate error-handlers for
> seperate error types.
>
> what are the objections to this idea?
Basically because you are hardcoding the rule with which you select
exceptions in the type attribute.
If someone wants to do a different select, he will use type and then
select... it's confusing, and unnecessary.
The more we put in the sitemap, the more we have to handle.
Selectors are already here, let's not invent different ways to do the
*same* thing.
--
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
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
On Wed, Jul 10, 2002 at 02:43:37PM +0200, Sylvain Wallez wrote:
> Michael Melhem wrote:
>
> >Dear Cocoon community,
> >
> >It seems to me that pipelines can only handle two error cases: Namely
> >error 500 (General Exception) and error 404 (ResourceNotFoundException).
> >
> >There appears to be no way currently to handle specific errors that might
> >be thrown by pipeline components other than to render a general Error 500
> >page. Am I mistaken?
> >
> >For example, it may be the case that a custom built generator could throw
> >custom Exceptions that a developer would like to handle in a specific
> >fashion.
> >
> >To that end, I propose that pipeline be extendend so that it they can
> >handle X number of errors depending on the amount of <map:handle-errors>
> >defined in the sitemap for that pipeline.
> >
> ><sitemap>
> > ...
> >
> > <map:handle-errors type="500">
> > <map:transform src="stylesheets/error2html.xsl"/>
> > <map:serialize/>
> > </map:handle-errors>
> >
> > <map:handle-errors type="404">
> > <map:transform src="stylesheets/error2html.xsl"/>
> > <map:serialize />
> > </map:handle-errors>
> >
> > <!-- one more or extra error-handles -->
> > <map:handle-errors type="someSpecificException">
> > <-- "type" here could me some sort of short code or the actual
> > full name of the Exception class? -->
> > <map:transform src="stylesheets/SpecificError2html.xsl"/>
> > <map:serialize status-code="500"/>
> > </map:handle-errors>
> >
> > etc..
> ></sitemap>
> >
> >Does anyone see any problems with this approach? Comments?
> >
> >
>
> I like this, and proposed something similar back in december (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100739814405987&w=2)
>
> It didn't had much acceptance at that time both because it involved
> class names in the pipelines and because Nicola Ken was refactoring
> error notification ;)
>
> But I still would like to have something like this, as I think having to
> write a <handle-errors type="500"> and then using a <map:select> to
> select depending on the error type is counter-intuitive.
I agree, IMHO introducing selectors within an handle-error block (even though this is apperantly possible) will only serve to convolute the situation making the sitemap harder to read and extend.
What could be simpler (and more logical) than having an handle-error block for each type? Especially considering that each error-handler already has the type attribute.
>
> 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.
>
> 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). 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>
>
> 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 ?
Even independent of implementation detail, I like the idea of having seperate error-handlers for seperate error types.
what are the objections to this idea?
Regards,
Michael Melhem
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Michael Melhem wrote:
>Dear Cocoon community,
>
>It seems to me that pipelines can only handle two error cases: Namely error 500 (General Exception) and error 404 (ResourceNotFoundException).
>
>There appears to be no way currently to handle specific errors that might be thrown by pipeline components other than to render a general Error 500 page. Am I mistaken?
>
>For example, it may be the case that a custom built generator could throw custom Exceptions that a developer would like to handle in a specific fashion.
>
>To that end, I propose that pipeline be extendend so that it they can handle X number of errors depending on the amount of <map:handle-errors> defined in the sitemap for that pipeline.
>
><sitemap>
> ...
>
> <map:handle-errors type="500">
> <map:transform src="stylesheets/error2html.xsl"/>
> <map:serialize/>
> </map:handle-errors>
>
> <map:handle-errors type="404">
> <map:transform src="stylesheets/error2html.xsl"/>
> <map:serialize />
> </map:handle-errors>
>
> <!-- one more or extra error-handles -->
> <map:handle-errors type="someSpecificException">
> <-- "type" here could me some sort of short code or the actual
> full name of the Exception class? -->
> <map:transform src="stylesheets/SpecificError2html.xsl"/>
> <map:serialize status-code="500"/>
> </map:handle-errors>
>
> etc..
></sitemap>
>
>Does anyone see any problems with this approach? Comments?
>
>
I like this, and proposed something similar back in december (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100739814405987&w=2)
It didn't had much acceptance at that time both because it involved
class names in the pipelines and because Nicola Ken was refactoring
error notification ;)
But I still would like to have something like this, as I think having to
write a <handle-errors type="500"> and then using a <map:select> to
select depending on the error type is counter-intuitive.
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.
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). 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>
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 ?
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
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
On Wed, Jul 10, 2002 at 01:50:29PM +0200, Nicola Ken Barozzi wrote:
>
> Michael Melhem wrote:
> >Dear Cocoon community,
> >
> >It seems to me that pipelines can only handle two error cases:
> > Namely error 500 (General Exception) and error
> > 404 (ResourceNotFoundException).
>
> Wrong.
>
> >There appears to be no way currently to handle specific errors
> > that might be thrown by pipeline components other than to
> > render a general Error 500 page. Am I mistaken?
>
> Yes.
>
> >For example, it may be the case that a custom built generator could
> > throw custom Exceptions that a developer would like to
> > handle in a specific fashion.
>
> Sure.
> Make your Exception implement Notifying, and all the information you may
> need is in the generated xml and cen be taken from the environment.
>
Hmmm... I didnt know that...I will take a look into this!
Thanks.
Best Regards
Michael Melhem
> >
> >To that end, I propose that pipeline be extendend so that it they can
> >handle X number of errors depending on the amount of <map:handle-errors>
> >defined in the sitemap for that pipeline.
> >
> ><sitemap>
> > ...
> >
> > <map:handle-errors type="500">
> > <map:transform src="stylesheets/error2html.xsl"/>
> > <map:serialize/>
> > </map:handle-errors>
> >
> > <map:handle-errors type="404">
> > <map:transform src="stylesheets/error2html.xsl"/>
> > <map:serialize />
> > </map:handle-errors>
> >
> > <!-- one more or extra error-handles -->
> > <map:handle-errors type="someSpecificException">
> > <-- "type" here could me some sort of short code or the actual
> > full name of the Exception class? -->
> > <map:transform src="stylesheets/SpecificError2html.xsl"/>
> > <map:serialize status-code="500"/>
> > </map:handle-errors>
> >
> > etc..
> ></sitemap>
> >
> >Does anyone see any problems with this approach? Comments?
>
> There is no need for this.
> We just need a selector to select between errors inside handle-errors.
>
> Why didn't you know this?
> Because it's poorly documented.
> Who is the sucker?
> <ducking> ;-P
>
> Diana, there is a need for docs on error generation.
> Where do I start?
> (me lazy on docs and Andy Oliver kicks my butt for this ;-)
>
> --
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Diana Shannon <sh...@apache.org>.
On Wednesday, July 10, 2002, at 07:50 AM, Nicola Ken Barozzi wrote:
> Diana, there is a need for docs on error generation.
> Where do I start?
There are many ways to start.
A few ideas:
1. Ok, let's say you're totally pressed for time. A simple approach is
to write a few FAQs. Anticipate the kinds of basic questions
people might ask (as did Michael). Do your best to answer them,
even if you don't have time to delve into a lot of example
or conceptual detail. Users will appreciate the effort, no matter
how preliminary. Many times, user can then continue on their own
with these basic hints.
2. Let's say you just need to quickly illustrate how something is done.
Author a Snippet: simple overview (what it is), code, short explanation.
Write a FAQ that points to the Snippet.
3. Ok, you have more time and more info to share. Write a How-To.
Give concise instructions, but with a bit more detail. Again, make sure
an FAQ points to it.
4. Write a core doc. If no decent models/templates exist, follow these
simple
very tentative suggestions. Sometimes, if you have created any of the
above
three docs already, you can incorporate (or link to them) in this "core"
doc.
a. Warn readers if you are writing about non-release topic. Throughout,
point out differences between release and HEAD branches, as appropriate.
b. Write a short overview. Give readers some idea what the doc is about.
c. Advise readers if they need to know other concepts before reading the
doc.
Point them to any available background reading if it's available.
d. Start by providing some conceptual info first. Be careful not to
provide
too much implementation detail before you've explained the principal
ideas, either
through concepts or examples. IMHO, this is the main difference between
a how-to and a core doc: the amount of conceptual detail and examples.
e. Provide a simple example, explain it, and then provide a more complex,
real-world example. Users complain the doc examples are too trivial.
If it's easier, point to a few Snippets you may have already written.
f. Anticipate user problems or questions. Add tips, if necessary.
g. Summarize your doc. This gives you a chance to convey the main points
in a slight different way, to reinforce what's important to the reader.
Anyone care to comment on this rough sketch?
> (me lazy on docs and Andy Oliver kicks my butt for this ;-)
Thanks Andy ;-) and thanks Ken!
-- Diana
Re: [PROPOSAL] Extending Sitemap Error Handling
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Michael Melhem wrote:
> Dear Cocoon community,
>
> It seems to me that pipelines can only handle two error cases:
> Namely error 500 (General Exception) and error
> 404 (ResourceNotFoundException).
Wrong.
> There appears to be no way currently to handle specific errors
> that might be thrown by pipeline components other than to
> render a general Error 500 page. Am I mistaken?
Yes.
> For example, it may be the case that a custom built generator could
> throw custom Exceptions that a developer would like to
> handle in a specific fashion.
Sure.
Make your Exception implement Notifying, and all the information you may
need is in the generated xml and cen be taken from the environment.
>
> To that end, I propose that pipeline be extendend so that it they can handle X number of errors depending on the amount of <map:handle-errors> defined in the sitemap for that pipeline.
>
> <sitemap>
> ...
>
> <map:handle-errors type="500">
> <map:transform src="stylesheets/error2html.xsl"/>
> <map:serialize/>
> </map:handle-errors>
>
> <map:handle-errors type="404">
> <map:transform src="stylesheets/error2html.xsl"/>
> <map:serialize />
> </map:handle-errors>
>
> <!-- one more or extra error-handles -->
> <map:handle-errors type="someSpecificException">
> <-- "type" here could me some sort of short code or the actual
> full name of the Exception class? -->
> <map:transform src="stylesheets/SpecificError2html.xsl"/>
> <map:serialize status-code="500"/>
> </map:handle-errors>
>
> etc..
> </sitemap>
>
> Does anyone see any problems with this approach? Comments?
There is no need for this.
We just need a selector to select between errors inside handle-errors.
Why didn't you know this?
Because it's poorly documented.
Who is the sucker?
<ducking> ;-P
Diana, there is a need for docs on error generation.
Where do I start?
(me lazy on docs and Andy Oliver kicks my butt for this ;-)
--
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