Code

Opened 5 years ago

Closed 10 months ago

Last modified 6 months ago

#11698 closed New feature (wontfix)

Add Django Debug Toolbar to contrib

Reported by: russellm Owned by: nobody
Component: Contrib apps Version: 1.1
Severity: Normal Keywords:
Cc: rob@…, chris@…, idangazit, ShawnMilo, djangoproject.com@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (0)

Change History (19)

comment:1 Changed 5 years ago by Rob Hudson <rob@…>

  • Cc rob@… added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 5 years ago by 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

comment:3 Changed 5 years ago by acdha

  • Cc chris@… added

comment:4 Changed 5 years ago by idangazit

  • Cc idangazit added

comment:5 Changed 4 years ago by russellm

  • Triage Stage changed from Unreviewed to Someday/Maybe

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.

comment:6 Changed 3 years ago by julien

  • Severity set to Normal
  • Type set to New feature

comment:7 Changed 3 years ago by gumuz

  • Easy pickings unset
  • UI/UX unset

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.

comment:8 Changed 3 years ago by acdha

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.

comment:9 Changed 3 years ago by ShawnMilo

  • Cc ShawnMilo added

comment:10 Changed 3 years ago by jezdez

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

comment:11 Changed 3 years ago by jezdez

  • Triage Stage changed from Someday/Maybe to Accepted

comment:12 Changed 3 years ago by jezdez

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

comment:13 Changed 3 years ago by haras

  • Cc djangoproject.com@… added

comment:14 Changed 13 months ago by loic84

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

comment:15 Changed 10 months ago by jezdez

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

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.

comment:16 Changed 10 months ago by aaugustin

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.

comment:17 Changed 10 months ago by mjtamlyn

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.

comment:18 Changed 10 months ago by jezdez

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

comment:19 Changed 6 months ago by aaugustin

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.