| Author: | Keryn Knight |
|---|---|
| Version: | 0.1.0 |
A reusable Django application which provides alternate templates for the error pages shown when DEBUG = True
These are heavily work-in-progress, as I think through the various bits...
Once upon a time, when the web was younger and simpler, I was a web designer. Times changed, the world of frontend exploded and things have changed enough that I'm not super familiar with things like Tailwind, nor as familar with TypeScript as I'd like.
To a degree then, this is just a toy repository for me to explore Tailwind and to a lesser extent, TypeScript.
Along the way, I may produce screens which are subjectively better than those currently bundled with Django, whose error pages have largely stood still (and arguably stood the test of time) since 2005.
- Maintain the same level of information the current debug pages have (because that's all the context data I have).
- Responsive.
- Dark mode support.
- Clarity of information. If it's harder to see the information, well, job failed.
- Accessible. Mostly because I don't know as much about modern a11y as I should.
- Ideally, reader mode friendly. I'm not sure how achievable that is, but it'd be super nice if the extraneous visuals could be stripped away by the browser.
- TODO :)
- Technical 404 page
- Technical 500 page
- ... others?
There's a number of differences between the data given to the 500 and 404 pages, which I'd need to get fixed upstream to be consistent, but that's likely a hard sell if they're not used ...
- Unfortunately, the context given to the 404 page doesn't include any of the following:
- The Django version (e.g.
4.0.1) - The Python version (e.g.
3.9.5) - The server time (e.g.
Fri, 21 Jan 2022 20:47:51 +0000) - The frame which caused the
Http404to be thrown.
- The Django version (e.g.
- Ideally the source lines shown in the template and traceback panels would be fixed up using
textwrap.dedentbased on the[top:bottom]being selected. - None of the contexts return the HTTP status code, which would mean having to hard-code the individual values if I wanted to suggest which HTML template would be rendered instead, in production. Not problematic, really ...