Opened 7 years ago

Closed 17 months ago

#7063 closed New feature (invalid)

More robust debugging output for AJAX with simple print statements in debug.py

Reported by: fred.palmer@… Owned by: nobody
Component: Core (Other) Version: master
Severity: Normal Keywords: ajax, debug, 500
Cc: Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Currently there is no debugging for AJAX calls that is easy to discern unless one looks at the response from an XmlHttpRequest. This is not always available or fast to do for all browsers. This is an attempt to solve that problem and allow the developer to simply look at the output from the runserver command.

Attachments (2)

debug.py.diff (686 bytes) - added by Fred Palmer <fred.palmer@…> 7 years ago.
Diff for the changes I'm suggesting
Picture 3.png (74.6 KB) - added by Fred Palmer <fred.palmer@…> 7 years ago.
Screen shot of the runserver output (very readable)

Download all attachments as: .zip

Change History (16)

Changed 7 years ago by Fred Palmer <fred.palmer@…>

Diff for the changes I'm suggesting

comment:1 follow-up: Changed 7 years ago by mtredinnick

You are making the assumption that that code is only executed under the development server, which isn't correct. It would be a bad idea to use print statements like that when running under most web servers: at a minimum the information will be totally discarded. I don't even like the idea of changing it to print to stderr, which is the real place to send debug prints (it's a bit too much information to send to the debug log). Using prints really isn't a great debugging technique in these circumstances (particularly prints in addition to the normal output).

I think you need a better idea here.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 7 years ago by Fred Palmer <fred.palmer@…>

Replying to mtredinnick:

You are making the assumption that that code is only executed under the development server, which isn't correct. It would be a bad idea to use print statements like that when running under most web servers: at a minimum the information will be totally discarded. I don't even like the idea of changing it to print to stderr, which is the real place to send debug prints (it's a bit too much information to send to the debug log). Using prints really isn't a great debugging technique in these circumstances (particularly prints in addition to the normal output).

I think you need a better idea here.

I'm not making the assumption that this code is only executed under the development server. So why is it bad idea? Does it mess with log parsing? From a cost-only perspective, the cost of doing this is negligible and very useful given the problem that I'm trying to solve. Perhaps a test of whether the code is running in a debug context would be a better option?

Thanks

comment:3 in reply to: ↑ 2 ; follow-ups: Changed 7 years ago by mtredinnick

Replying to Fred Palmer <fred.palmer@gmail.com>:

I'm not making the assumption that this code is only executed under the development server.

Printing to stdout interferes with the normal output path in many webserver setups (e.g. fastcgi). In other cases, it doesn't go anywhere. Except for the special case of Django's development server, printing to stdout is somewhere between dangerous and a waste of cycles.

So why is it bad idea? Does it mess with log parsing?

It certainly dumps a lot of stuff in the logs. But it's also not particularly readable (and it's not hard to end up with error messages intermixed with each other, which makes debugging quite tricky). If we're putting in extra debugging output of any nature, it should be completely robust and not likely to cause confusion. Otherwise we might as well just stay as we are now where people can easily drop print statements into their own code to work out what's going on or inspect things on the browser side.

Shared hosting and access to error logs is another issue.

Perhaps a test of whether the code is running in a debug context would be a better option?

The function you're trying to patch is only executed when DEBUG=True.

There are some other tickets open to try and create a better "when using Ajax" debug output that avoids the particular function you're trying to amend. That's probably a better approach. I'll leave this open for now in case there's a better idea that pops up, but putting in more print statements doesn't feel like a particularly good solution to have in core.

Changed 7 years ago by Fred Palmer <fred.palmer@…>

Screen shot of the runserver output (very readable)

comment:4 in reply to: ↑ 3 Changed 7 years ago by Fred Palmer <fred.palmer@…>

Replying to mtredinnick:

Replying to Fred Palmer <fred.palmer@gmail.com>:

I'm not making the assumption that this code is only executed under the development server.

Printing to stdout interferes with the normal output path in many webserver setups (e.g. fastcgi). In other cases, it doesn't go anywhere. Except for the special case of Django's development server, printing to stdout is somewhere between dangerous and a waste of cycles.

Why not make a test to see if "runserver" was the command line argument and only do this for the dev server? That gets rid of the danger.

So why is it bad idea? Does it mess with log parsing?

It certainly dumps a lot of stuff in the logs. But it's also not particularly readable (and it's not hard to end up with error messages intermixed with each other, which makes debugging quite tricky). If we're putting in extra debugging output of any nature, it should be completely robust and not likely to cause confusion. Otherwise we might as well just stay as we are now where people can easily drop print statements into their own code to work out what's going on or inspect things on the browser side.

I'm sorry to disagree... but it's very readable and I use extensively and so do my teammates. Please see the attached screenshot. Anyone doing Ajax needs something now to keep from having to copy the response in Firebug and past to web preview in TextMate. This would save tons and tons of time.

Thanks for your time and thoughts.

comment:5 Changed 7 years ago by ramiro

There is a nice and simple middleware that strips all the fancy formatting from the 500 response page at http://www.djangosnippets.org/snippets/650/. Using it you get simple to read tracebacks in Firebug without the risk of getting intermixed output.

You can even replace the detection logic with a call to the new is_ajax() HttpRequest method.

Also, that snippet can be used as a starting point for your own middleware that saves the debugging output to file(s).

comment:6 Changed 7 years ago by ericholscher

  • milestone set to post-1.0
  • Triage Stage changed from Unreviewed to Someday/Maybe

comment:7 Changed 6 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:8 in reply to: ↑ 3 Changed 5 years ago by akaihola

Replying to mtredinnick:

There are some other tickets open to try and create a better "when using Ajax" debug output that avoids the particular function you're trying to amend. That's probably a better approach. I'll leave this open for now in case there's a better idea that pops up, but putting in more print statements doesn't feel like a particularly good solution to have in core.

Malcolm may be referring to #10841 here.

comment:9 Changed 4 years ago by lukeplant

  • Severity set to Normal
  • Type set to New feature

comment:10 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:11 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:12 Changed 2 years ago by aaugustin

  • Component changed from Uncategorized to Core (Other)

comment:13 Changed 17 months ago by aaugustin

Browser dev tools have improved a lot since this ticket was filed. Is it still relevant?

comment:14 Changed 17 months ago by mjtamlyn

  • Resolution set to invalid
  • Status changed from new to closed

I don't think this would be relevant any more.

Note: See TracTickets for help on using tickets.
Back to Top