From: "Peter Robins" <[EMAIL PROTECTED]>
> In my 2.0 setup, I had a map:handle-errors with a simple map:read of an
html
> 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
something
> 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
serializer?).
> I tried adding read to the DTD but this had no effect - which didn't
surprise
> 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
doesn't
> 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
useful.
[Has anyone arguments against this?] ;-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- 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. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
