[Zope-dev] standard_error_message and displaying non-html content.

Fri, 19 Oct 2001 16:57:03 +0100

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.