Nicola, istm you are making 2 false assumptions: 1. all errors are program errors 2. only the people who set up the site use it
In any properly tested system, internal server errors and the like shouldn't (!) occur. Even if they do, there is nothing the user can do about it, so there's no point in telling them, apart perhaps from a simple message that there's a problem - please try again later or whatever. If a user gets a list of exceptions/java classes/whatever comes out of the generator, they won't understand a word of it anyway. The site administrator needs a report, so the problem can be fixed, but will get that from the logs. In my experience, by far the commonest error is page not found, and by far the commonest cause of that is that the user has mistyped the url (or clicked on an incorrect link). So all they need is a simple message saying 'page not found, please check what you entered' - a simple read of an html file is surely the simplest way of doing this. More user-friendly is to give them the message together with a standard menu of links to click on, which is why I was wanting an aggregate, but I'm not really bothered which map element is used to provide the page, whatever makes most sense. HTH p.s. if the sitemap compiler could similarly provide a more user-friendly message such as 'sitemap won't compile - pls check your xml is valid' instead of inscrutable messages about sitemap handlers, the amount of traffic in this list should decline significantly :-) p.p.s. don't have any arguments against your last point - TIA for any improvements On Friday 15 Mar 2002 5:21 pm, Nicola Ken Barozzi wrote: > > 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?] ;-) --------------------------------------------------------------------- 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]>
