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

[fred.palmer@…]

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.

[Fred Palmer <fred.palmer@…>]

Diff for the changes I'm suggesting

[Malcolm Tredinnick]

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.

[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

[Malcolm Tredinnick]

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.

[Fred Palmer <fred.palmer@…>]

Screen shot of the runserver output (very readable)

[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.

[Ramiro Morales]

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).

[(none)]

Milestone post-1.0 deleted

[Antti Kaihola]

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.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Aymeric Augustin]

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

[Marc Tamlyn]

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