I have now put the first (rough) draft of a proposal up on dev.zope.org. Please feel free to comment/modify/add suggestions. If anyone has a specific problem with standard_error_message which my proposal does not address, please feel free to contact me. I will be away from the office for the next two weeks, and won't be reading email very often, so I won't be able to contribute much for a while. Trevor Toenjes writes:
I wanted to throw 2 cents in to this thread from my previous problems/questions about error_message. I think they are slightly related. Maybe someone can filter my newbie-isms and use some of this in the Dogbowl. I would like to have more control over the standard_error_message auto-rendering of error_message and error_tb. These should be treated more like "typical" methods in Zope to be consistent with everything else. (like standard_html_header) ;) -Trevor
What is error_message? Where does the autoformatting come from, and how do I alter it? Can I modify it to just grab the error and not all the other Zope stuff?
You can't, as far as I can see. I have included in my proposal that the traceback information should be html free.
Why is this so stealthy compared to the rest of Zope? I don't think it's stealthy. The problem is that it is assumed you will be targetting web browsers.
Why should I have to "turn off" debugging for tracebacks to be commented out in the HTML? With my Zope understanding so far...if it is an object, then I can include it or not in my standard_error_message. So why is it hardcoded in Zope? Example: If I have error_tb in my standard_error_message, then it renders, if not - it's hidden. Current Zope renders it anyway. Why isn't it treated like an object like the rest of Zope?
Part of the problem here is that Zope has to handle the case where standard_error_message raises an exception. If that happens, where does Zope get it's error response. To handle this case, ZPublisher/HTTPResponse.py contains a copy of the standard Zope traceback, and uses this if an error occurs during standard_error_message.
Is there a library of these error messages that can be modified to provide better information for users to find what they are looking for. They come from somewhere? Not sure that there is a library as such. At least some of them are defined in ZPublisher/HTTPResponse.py, but others come from whatever traceback occurred.
Formulator allows you to customize your error messages. It would be great if Zope_Error handling were that >friendly.
Can't comment on Formulator - never used it.
Please look at my proposal on dev.zope.org and see if it addresses your particular case - if not, please add a comment or email me.
Steve Alexander writes:
seb bacon wrote:
I don't believe there is a clean way. I've changed the source not to display its own html at all. It's not nice, but I suppose that's the benefit of OSS.
Is there a FishBowl proposal on remedying this? If not, there should be one.
Perhaps someone who has this itch to scratch can get the ball rolling?
First, thanks for the quick response.
Secondly, I would be willing to start this process, but my knowledge of Zope internals is patchy at best, so I might not be the best person for this. Still, if no-one else wants to, I will give it a go.
Just to clarify, I am only concerned at present with the code in HTTPResponse that, in the case of an exception, scans for <!doctype html or <html, and wraps them in html if these are not found. (Seb, does this cover the problems you experienced?)
I think there is a more general problem of making Zope "content-neutral", but that is a proposal for another time.
Regards,
Noel Duffy.
Cheers, Noel.