|Django Error Display Page||Matt||6/8/11 3:50 AM|
I have been thinking about this for quite a long time.
Can you make an error display page less verbose?
I mean not to exclude those useful information, but to initially fold (hide) them.
Fold those items:
- Python path at the top yellow background.
- (Hide or fold) django traceback entries
When I have a problem I have to scroll down (passing django calls) few pages until I am able to find which MY action caused an error.
I know looking at django callback may be useful, but in my case, hardly ever, and probably for newcommers also.
I am imagining this like that:
At the top of the error page, there are tabs.
Summary, Traceback, Request, Settings, and copy-paste view (feedback view).
Summary tab, contains this yellow background information with PYTHON_PATH initially folded, and traceback filtered out to include only information from project not calls from django itself.
Traceback, request and settings tabs as it is right now, but separated for easy of view.
copy-paste (feedback) - a standardize view for easy of copy-and-paste to the Internet message boards, groups and so on...
It would need a template refactor and some more js involved, should not be a hard thing to do.
I read that there is a plan to redesign an error page, but since then, those modifications should do the job.
What do you think?
|Re: Django Error Display Page||Graham King||6/8/11 9:10 AM|
This ticket might be a part of what you're looking for:
It proposes to dim the django parts of the stacktrace, so the code
which most likely caused the error stands out better, which is
certainly something I'd love to see.
There's some similar ideas discussed here:
|Odp: Re: Django Error Display Page||Matt||6/8/11 9:44 AM|
Colored output of the trackeback does not solve my problem of scrolling few screens in order to find whats happening, or use cmd-F key to quick jump.
I think this is not a good way to do this.
What's I am thinking is a tabs at the top which manipulates with visibility of certain divs of error page.
A quick temporary fix, before complete redesign of error page.
|Re: Re: Django Error Display Page||Yuri Baburov||6/8/11 8:36 PM|
I think, adding a link at top, getting you to the end of traceback
e.g, top line with exception type and URL could be a link moving you
What do you think?
Smart (colored) traceback could change that to moving to the last
> --> https://groups.google.com/d/msg/django-developers/-/d0F2R2NvWkJNQ3NK.
|Re: Django Error Display Page||Tom Evans||6/9/11 1:51 AM|
I disagree entirely. The stack trace is the first thing I look at, and
I also strongly disagree about manipulating the traceback at all. Why
Besides which, if the django error page is not what you desire, you
|Re: Django Error Display Page||Jonathan Slenders||6/9/11 6:29 AM|
Me too. Why is it that I we have a huge Python Path, the Python
revision number and executeble locations on Top. Further, the
Exception value is displayed twice, and the request URL is also shown
in the address bar. The server time is also not that important that it
has to be shown above the stack trace.
I know it is possible to use a custom template for this, but I think
most people only want to see the Exception message, and the traceback
without scrolling down a whole page...
|Re: Django Error Display Page||Idan Gazit||6/9/11 7:16 AM|
The technical 500 page does display a lot of information, but debugging a failure is all about information.
#11834 is helpful (dims django frames) without getting in the way (hiding things). For now, this is a good example of a helpful change with minimal negative impact.
I'm sure the 500 page could be better, but I'd need to see a concrete proposal outlining the problems and how the improvements address these problems. Right now this feels like a case of fixing what ain't broken.
On Wednesday, June 8, 2011 at 6:10 PM, Graham King wrote:
> This ticket might be a part of what you're looking for:> > To post to this group, send email to django-d...@googlegroups.com (mailto:django-d...@googlegroups.com).
> > django-develop...@googlegroups.com (mailto:email@example.com).
> --> To post to this group, send email to django-d...@googlegroups.com (mailto:django-d...@googlegroups.com).
> To unsubscribe from this group, send email to django-develop...@googlegroups.com (mailto:firstname.lastname@example.org).
|Re: Django Error Display Page||Valentin Golev||6/9/11 8:31 PM|
What I'd really like is a stacktrace in a plain text in the html
commentary ("<!-- ... -->") on the very top of the page.
This really would save me from curl's output reading nightmare without
losing all browser-understandable happiness
|Re: Django Error Display Page||Dougal Matthews||6/10/11 12:34 AM|
This would actually be very useful when debugging Ajax calls in browsers. I often find myself reading the HTML particularly in chrome where I think the only other option is to save the file and re-open it.
|Re: Django Error Display Page||Stephen Burrows||6/10/11 6:05 AM|
That would be useful for Chrome and Safari, and probably pretty easy
to implement. (For Firefox, I like to use the Modify Headers add-on
 and spoof the AJAX request - then I can browse the error page in
its full glory. :-) )
|Re: Django Error Display Page||Wim Feijen||6/10/11 7:42 AM|
For me, it would definitely be a good idea to change the error page a
bit, so at least the actual error message is not in grey but in black,
and bigger. People tend not to see it right now, because it looks
|Re: Django Error Display Page||Daniel Watkins||6/10/11 1:11 PM|
On Thu, Jun 09, 2011 at 08:31:44PM -0700, Valentin Golev wrote:
I've opened https://code.djangoproject.com/ticket/16227 with patch
|Re: Django Error Display Page||David Cramer||6/10/11 9:21 PM|
def process_exception(self, request, *args, **kwargs):
if not request.is_ajax(): return
On Jun 10, 1:11 pm, Daniel Watkins <dan...@daniel-watkins.co.uk>
|Re: Django Error Display Page||Matt||6/11/11 1:20 AM|
Why not to give ability to chose by the developer?
as it is
DEBUG_VIEW = 'tabbed'
DEBUG_VIEW = 'default'
IMHO: DEBUG_VIEW is better and more extensible in future.