Skip to content

Another take on AJAX panel #356

wants to merge 14 commits into from

10 participants

zifot commented Feb 18, 2013


I supplemented the work of @tobiasmcnulty from django-debug-toolbar/django-debug-toolbar#253 to move the whole idea of an AJAX panel a little bit forward. I'm looking forward to your feedback.

tobiasmcnulty and others added some commits Jan 15, 2012
@tobiasmcnulty tobiasmcnulty First shot at ajax requests panel
This is a rebase+squash of the original commits by Tobias McNulty (@tobiasmcnulty),
taken from pull request django-debug-toolbar/django-debug-toolbar#253, with some
minor changes to resolve merge conflicts.
@zifot zifot Storing toolbar DOM for AJAX requests in the cache instead of session 695f2b9
@zifot zifot Tests for DebugToolbarMiddleware.process_response
Making incoming changes easier and safer.
@zifot zifot Refactorization 404d932
@zifot zifot Fixing AJAX request handling
DOM tree of a toolbar for AJAX requests was not stored on
the server.
@zifot zifot Handle lack of session middleware in Ajax panel so that existing test…
…s pass again

Ajax panel requires session middleware (for session id),
but existing tests run without it. So the ones executing
panel.process_request were failing.

TODO: Panel probably shouldn't fall back to no-op silently just
like that, but rather throw an exception or return some diagnostic
@zifot zifot Don't send js code again with the toolbar DOM for AJAX requests
Sending the whole jQuery and toolbar js code over and over again
doesn't really makes sense, plus:

- it makes debugging js code harder or impossible after toolbar
for first AJAX call is loaded
- in some situations it may require cleaning up callbacks

Changes to toolbar.js:
- actions from djdt.init that should be performed only once (during
initial page load) are moved to djdt.setup
- those that need to be performed with each toolbar reload stays
within djdt.init
- both djdt.setup and djdt.init are called on dom ready
- djdt.init is also called after receiving new toolbar DOM for one of
the AJAX requests selected in the Ajax panel
@zifot zifot Ignore internal AJAX requests d3d6411
@zifot zifot Ajax panel: Allow to jump to initial (non-ajax) request d613e10
@zifot zifot Cleanup 49f7952

This is awesome!
We are developing a completely ajax-driven site and we will definitely use this.

zifot added some commits Feb 24, 2013
@zifot zifot Exempt Ajax panel cache operations from tracking by Cache panel
Cache panel displays arguments that were sent to the cache methods
(they are rendered in the toolbar's template). And because Ajax
panel stores toolbar's templates in the cache (by calling cache.set)
this leads to a geometric grow in the amount of data being stored
as each subsequent template sent to the cache contains content of all the
templates stored previously (as rendered by the Cache panel).

This can quickly lead to template sizes in tens of megabytes after
only a handful of AJAX requests.

On top of that, that data isn't actually interesting from the debugging
point of view.
@zifot zifot Highlight currently displayed request in the Ajax panel f7abefe
@zifot zifot Don't render list of requests for nothing
The list of requests that should be displayed in the Ajax
panel changes dynamically with each request. Toolbar's DOM
trees for the old requests shouldn't hold this list as it
may be obsolete by the time such a tree is loaded into the
browser (e.g. when going back to examine old request) and
up to date list is always fetched via Ajax call anyway.
ebertti commented Feb 26, 2013



The javascript file does not seem to be minified.

I would be nice to be able to see SQL-queries and other panels for the request also. Its nice to see how many and what sql gets generated for ajax-requests. (My bad.)

zifot commented Feb 26, 2013

@akarl818 That's the way it's working right now - if you click a specific request on the requests list, all panels will show information regarding that specific request. Or did you mean something like aggregated information for all AJAX requests?

zifot commented Feb 26, 2013

OTOH the usability of how it all works right now could be better - I'm thinking about something along the lines of displaying some kind of a drop down menu that would list all the requests available and that would be accessible in other panels or/and around the main sidebar. Any thoughts?


That dropdown could be realy nice :)

On line 142-143 in

if ('gzip' not in response.get('Content-Encoding', '') and
                response.get('Content-Type', '').split(';')[0] in _HTML_TYPES):

_HTML_TYPES is ('text/html', 'application/xhtml+xml') witch means that if the response is for example application/json then it does not get through to the panel.

@jezdez jezdez commented on the diff Mar 2, 2013
+import inspect
+import datetime
+from contextlib import contextmanager
+from django.core.cache import cache
+from django.utils.translation import ugettext_lazy as _
+from debug_toolbar.panels import DebugPanel
+def disable_tracking(cache):
+ cache._django_debug_toolbar_do_not_track = True
+ yield
+ del cache._django_debug_toolbar_do_not_track
+class Storage:
django-debug-toolbar member
jezdez added a note Mar 2, 2013

Please use a new style class here for improved subclassing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
rouge8 commented Sep 11, 2013

Would it be worth trying to bring this PR up to date and doing some cleanup?


I've brought @zifot's branch up to date here tim-schilling@2020abc

@jezdez I'm not quite sure what you mean by a new style class, could you clarify what you're looking for?

django-debug-toolbar member
jezdez commented Nov 2, 2013

@tim-schilling The patch uses old-style (class Storage:) instead of new-style Python classes (class Storage(object):. The latter has a vastly improved inheritance scheme and offers other important features (see


I just discussed this feature with @jezdez, and given our limited resources for maintaining the toolbar we prefer that this feature live as a 3rd party panel. My recent changes to delay the rendering of panels may help.

If you release it, please send us a pull request adding it to the list of third-party panels in the documentation!

@aaugustin aaugustin closed this Nov 23, 2013

If you release it, please send us a pull request adding it to the list of third-party panels in the documentation!

Similarly here. If anyone does tackle this then please open an issue for it to be linked too from the Django REST framework documentation.

Likewise, if anyone has input on what they'd like to see in an AJAX panel please feel free to notify the Django REST framework discussion group so it can be discussed there.

djsutho commented Jul 28, 2014

Not sure if anyone is still interested in this but I made a third party panel which supports ajax requests:
Its a bit rough but works well enough for me. I would appreciate any comments.

@tomchristie where in the Django REST framework documentation would this be linked?


@djsutho We have a list of third-party panels in the docs. If you want yours to be included there, please submit a pull request!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.