cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject Let's improve <handle-errors/> (was: Re: Contents of map:handle-errors?)
Date Fri, 15 Mar 2002 17:21:07 GMT
From: "Peter Robins" <>

> In my 2.0 setup, I had a map:handle-errors with a simple map:read of an
> file. This worked fine. However, with 2.0.1, this no longer compiles.

It shouldn't have compiled; the sitemap checks have become stricter.

>  I
> looked in the documentation (yes, really!): sitemap.html describes
> called map:error-handler (I assume this is an, er, error) and says that
> "you do not define a generator inside the error handler. Beside this
> issue you configure the error handler like a pipeline. Thus you can choose
> your transformer, and serializer, and all other features of pipeline
> processing"

This is correct.

> If I look in the DTD on the other hand it tells me I can have generators,
> xformers and serializers (sic: what would I do with more than 1
> I tried adding read to the DTD but this had no effect - which didn't
> me, as afaics the DTD isn't actually used by anything.

Ok, then the DTD is wrong. I'll have to patch it.

> Although read would, istm, be the simplest way of handling page not found
> errors, what I actually want to do is an aggregate, but the compiler
> like that either. Nor does it like a redirect or the cocoon:/ protocol.
> So, how can I get a handle on this error, and handle without error those
> errors that the handle-errors error-handler won't handle?  ;-)


You brought out a thing that has been already discussed al lot on
cocoon-dev, but AFAIK we didn't reach a conclusion that satisfies all.

I hope you users can give me some hints on what you want. "Has anyone
arguments against this?" in the following text are the points I would like
to have feedback on.

 Design decisions on handle-error

When I made the handle-error pipeline, I thought that it was made to notify
the user of what went wrong.
So I made up a simple DTD for it, and decided to keep it fixed.
[Has anyone arguments against this?]

To prevent misuse of this part of the pipeline that can come if you can
define any Generator in it, I decided to keep the Generator fixed. The user
can then manipulate the error XML to fit any style it needs.
[Has anyone arguments against this?]

There is also a need to access the error contents by actions and selectors.
So I recently changed the works of this internally, and the sitemap model
contains the error notification as an object, enabling it to be used by
actions, selectors, etc.
[Has anyone arguments against this?]

Redirecting in this pipeline could be a problem, since it can redirect to a
pipeline that has an error, which redirects to another one that has an
error, and so on.
[Has anyone arguments against this?]

Using a Reader makes the recursive error problem still possible, since the
Reader can read the pipeline it comes from, or any other pipeline that
generates an error.
[Has anyone arguments against this?]

So, all these decisions mave the error handling what it is today.
Comments, suggestions and constructive criticism is very welcome :-)

So if I get enough feedback, I will modify <handle-errors> to make it more
[Has anyone arguments against this?]    ;-)

Nicola Ken Barozzi         
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

Please check that your question has not already been answered in the
FAQ before posting. <>

To unsubscribe, e-mail: <>
For additional commands, e-mail: <>

View raw message