standard_error_message and displaying non-html content.
I have a zope site where users can access content using either html browsers and non-html devices, wap/wml, voicexml etc. I want to customize the standard_error_message dtml document to display errors in the appropriate format for each user. For example, if a user tries to access a non-existent url from a wml browser, they should get a nice wml page back saying that the page was not found. Heres the problem. Although I have customized standard_error_message to display a page in the right format, the code in ZPublisher/HTTPResponse.py (exception method of HTTPResponse class) checks the error page I generate and, if it doesn't see "<html>" or "<!doctype html" at the start of the page, it wraps my page in some html by calling _error_html. Thus I get a small wml page wrapped in html :-( It makes no difference what the content-type header is set to - I'm setting that correctly for the users browser. Is there any clean way I can alter this behaviour short of changing the code in ZPublisher/HTTPResponse.py? I say clean because I did find a rather ugly hack that will work - it involves replacing a method of the RESPONSE object at run-time. Not nice! Thanks in advance Noel Duffy. -- Noel Duffy Senior Software Engineer www.propylon.com Tel: +353 96 36038 Fax: +353 96 36353
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. These days I have a whole pile of patches I have to apply to each Zope I install :S seb * Noel Duffy <noel.duffy@propylon.com> [011017 14:55]:
I have a zope site where users can access content using either html browsers and non-html devices, wap/wml, voicexml etc. I want to customize the standard_error_message dtml document to display errors in the appropriate format for each user. For example, if a user tries to access a non-existent url from a wml browser, they should get a nice wml page back saying that the page was not found.
Heres the problem. Although I have customized standard_error_message to display a page in the right format, the code in ZPublisher/HTTPResponse.py (exception method of HTTPResponse class) checks the error page I generate and, if it doesn't see "<html>" or "<!doctype html" at the start of the page, it wraps my page in some html by calling _error_html. Thus I get a small wml page wrapped in html :-( It makes no difference what the content-type header is set to - I'm setting that correctly for the users browser.
Is there any clean way I can alter this behaviour short of changing the code in ZPublisher/HTTPResponse.py? I say clean because I did find a rather ugly hack that will work - it involves replacing a method of the RESPONSE object at run-time. Not nice!
Thanks in advance
Noel Duffy.
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? -- Steve Alexander Software Engineer Cat-Box limited
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.
On Thursday 18 October 2001 10:19 am, Noel Duffy allegedly wrote: [snip]
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.
I think the way to proceed is to create a fishbowl proposal to change ZPublisher so that no HTML wrapping takes place if the Content-Type is some thing other than "text/html". Unfortunately changing "magic" like this has a tendancy to break code that unwittingly relies on it. The fishbowl allows everyone to give that due consideration. I think this is a great idea BTW. /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/
I think the way to proceed is to create a fishbowl proposal to change ZPublisher so that no HTML wrapping takes place if the Content-Type is some thing other than "text/html".
Unfortunately changing "magic" like this has a tendancy to break code that unwittingly relies on it. The fishbowl allows everyone to give that due consideration.
I think this is a great idea BTW.
Yeah it would be useful since I currently check to see if the request is an xmlrpc one to return xml instead of html. This may be simply part of the new component architecture to have text/plain treated differently. Cheers. -- Andy McKay.
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?
Why is this so stealthy compared to the rest of Zope? 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?
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? Formulator allows you to customize your error messages. It would be great if Zope_Error handling were that >friendly.
-----Original Message----- From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org]On Behalf Of Noel Duffy Sent: Thursday, October 18, 2001 10:20 AM To: Steve Alexander Cc: seb bacon; zope-dev@zope.org Subject: Re: [Zope-dev] standard_error_message and displaying non-html content.
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 - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
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.
participants (6)
-
Andy McKay -
Casey Duncan -
Noel Duffy -
seb bacon -
Steve Alexander -
Trevor Toenjes