Add Django Debug Toolbar to contrib

[Russell Keith-Magee]

Rob Hudson's ​Django Debug Toolbar should be considered for inclusion in django.contrib.

There are some issues that need to be resolved - in particular, the usage of jQuery in rendering the UI. There is also a need to determine the set of plugins that will be shipped by default. Some UI polish may also be required.

[Rob Hudson <rob@…>]

See: ​http://groups.google.com/group/django-developers/browse_thread/thread/8d6e4d7d163db943?hl=en

[mrts]

Can some of the improvements by dcramer, in particular profiling support which is very useful, be also integrated? See ​http://github.com/dcramer/django-debug-toolbar/tree/master

[Russell Keith-Magee]

DDT is a great tool, but we're not going to integrate it before Rob is happy with it. It can live quite happily as an external project in the meantime.

[gumuz]

After discussing this with Jannis, here are some ideas of how something like this might work:

Instead of having middleware appending html content to the response like it does now, debug data can be stored server-side so it can be requested on demand using javascript for example.

Storing this data might be done using the existing logger infrastructure. This basically turns the whole debug toolbar into a live log viewer, but with the addition of structured/serialized debug data embedded into the log messages, which makes it possible to present this data in a useful way. Some care has to be taken to ensure the the data is only from the viewers session and that individual requests can be identified.

The advantages of this approach are that the data is not inserted as html anymore and is not restricted to just the current request. This way for example also enable ajax request/response inspection.

[Chris Adams]

The Chrome SpeedTracer (​http://code.google.com/webtoolkit/speedtracer/) API does something similar: the server simply provides a header containing a URL to retrieve trace data for instrumented clients. I implemented this in ​https://github.com/acdha/django-speedtracer simply by storing the report data in the cache using a UUID for each request. This approach worked really well both for performance - no problems like debug-toolbar has generating huge HTML stack traces for a page which accidentally does too many queries - and it's easy to have this pulled out using XHR or even, assuming some sort of user-keyed storage, retrieved from another machine in context such as mobile development where the client doesn't have your diagnostic tools.

[Jannis Leidel]

@acdha Wow, that looks really good, +1 on using that approach. Combined with DDT's panels for data collection this would be great.

[Jannis Leidel]

FTR, there was some work done to revamp the way the toolbar injects itself in the page at ​https://github.com/Maykin/django-debug-toolbar/commits/master

[loic84]

Is there still a long term goal of adding DDT to django.contrib?

[Jannis Leidel]

Marking as wontfix since we're increasingly removing apps from contrib and are promoting standard Python packaging tools instead. FTR, I'm a committer to the debug toolbar and would happily encourage feedback about it.

[Aymeric Augustin]

jezdez, do you think we should point to the DDT in the tutorial?

It's probably the most widely used addon for Django after the admin.

[Marc Tamlyn]

This comes back to the whole concept of recommended external packages in the docs. I'm +0 on the idea, but it's not a discussion for this ticket.

[Jannis Leidel]

aaugustin, sure why not -- as soon as DDT has a Django > 1.5 and Python 3 compatible release out.

[Aymeric Augustin]

DDT 1.0 was released with support for Django 1.4+ and Python 2.6+/3.2+.