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) ;)
> > 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
> > 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,
> > 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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -