Ticket #800 (enhancement)
Opened 4 months ago
Last modified 2 months ago
Request ability to override default error template (replaces ticket #795)
Status: closed (fixed)
| Reported by: | schapman@mischko.com | Assigned to: | fumanchu |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.1 |
| Component: | CherryPy code | Keywords: | |
| Cc: |
It would be nice if we could specify a default error template file.
Simply changing _cperror.py lines 276-280 CP_303:
# Replace the default template with a custom one?
error_page_file = cherrypy.request.error_page.get(code, '')
if error_page_file:
try:
template = file(error_page_file, 'rb').read()
to this:
# Replace the default template with a custom one?
error_page_file = cherrypy.request.error_page.get(code, '')
# If there's no custom one for that error number, is there a default?
if not error_page_file:
error_page_file = cherrypy.request.error_page.get(0, '')
if error_page_file:
try:
# If it's a Python file, import everything from it.
if error_page_file.split('.')[-1].lower() == 'py':
exec('from %s import *' % error_page_file.split('.')[0])
if 'kwargs_update' in locals():
kwargs.update(kwargs_update)
# Otherwise, it's just a template in a file.
else:
template = file(error_page_file, 'rb').read()
Would change things:
- Defining a default error page handler (where N is the error page number):
- 'error_page.N': 'error_config.py', or
- 'error_page.N': 'error_config.foo'
- If N is 0, the error_page template will be used in place of the built-in default.
- Custom error pages are imported if they end in ".py". Otherwise they are read in.
- Imported pages can include a kwargs_udpate dictionary which will be included in the kwargs, if present.
This is completely backwards compatible.
Attachments
Change History
03/19/08 11:34:30: Modified by fumanchu
- owner changed from rdelon to fumanchu.
- status changed from new to assigned.
- milestone set to 3.1.
03/25/08 19:40:36: Modified by fumanchu
- attachment error_page_callable.patch added.
03/25/08 19:43:15: Modified by fumanchu
The attached error_page_callable.patch works, but I'm not 100% happy with it yet. There needs to be an obvious balance between complete flexibility and the safety provided by e.g. clean_headers, and IMO just asking everyone who implements an error_page callable to remember to set the status and call clean_headers isn't good enough. Somehow those safety features should be "on by default" but easy to turn off.
04/05/08 15:41:01: Modified by fumanchu
Branched in [1941].
04/26/08 17:50:27: Modified by fumanchu
- status changed from assigned to closed.
- resolution set to fixed.
Trunked in [1949].


That's starting to get messy IMO. I think, rather than chasing ever-more-complicated templating declarations, we'd be better off just allowing users to call arbitrary callables instead of HTTPError.set_response:
Then the user could set the response status, headers, and body however they liked. I've got this coded up but not passing the test suite yet.