Debugging of ajax and saving reports #26

wants to merge 3 commits into


None yet

3 participants


This patch makes it possible to debug ajax calls and json/javascript based api calls together with facilities to force debugging and saving reports (slow ones for example) somewhere.

New config variables:

DEBUG_TB_FORCE_DEBUG_PARAMETER - specifies GET parameter to force debugtoolbar activation. Might be used for debugging ajax request and json/javascript-typed responses.

DEBUG_TB_DUMP_CALLBACK - if set enables profiling (but not showing debugtoolbar) for all requests. Specifies function that will be called after each request with toolbar html provided.

mgood commented Apr 17, 2012

Interesting. Yeah, it would be useful to get back to the debugging info for the background AJAX calls. I guess you're using the callback to save the HTML somewhere? What might be nice is to save the last N requests and display that request history within the toolbar itself so that you can more easily browse it.


In my case I use it for both testing of ajax calls and for profiling of API calls wich retur json.
And the callback is used indeed for saving html somewhere so it can be browsed and analized later. In particular it helps catching and investigating slow or heavy requests on live by forcing profiling on one of live servers and saving reports for requests that satisfy some conditions (i.e. take more than x second for example).

jbremer commented Mar 16, 2014

I was wondering if there are any plans to either develop this feature further, as it's something I'd definitely be interested in, and I'm sure others are as well :)
For now I'll definitely check out the patch, which surely suffices, but it would be awesome if stats are updated on-the-fly in the debug toolbar.

Other than that, great plugin, it helps me a lot all the time.

@mgood mgood added a commit that referenced this pull request Apr 15, 2015
@mgood Move process_response logic into overridable methods
This would allow users to subclass and extend the behavior more easily for
custom processing of the toolbar response. This should fulfill the
extensibility requested in #26, but with more direct control over the response.
mgood commented Apr 15, 2015

I was looking at this again, and I think that rather than hooking into the response processing via configuration values, it might be simpler to move the logic you're asking to extend into methods, so that it could be overridden by a subclass. I've pushed a possible implementation above to the "process-response-hooks" branch. Subclassing would look something like:

class MyToolbar(DebugToolbarExtension):
    def should_process_response(self, response):
        if DebugToolbarExtension.should_process_response(self, response):
            return True
        return my_custom_check

    def insert_toolbar(self, toolbar_html, response):
        # custom processing of toolbar_html ...
        if DebugToolbarExtension.should_process_response(self, response):
            response = DebugToolbarExtension.insert_toolbar(self, toolbar_html, response)
        return response
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment