We Keep Coding

Django figure out which template rendered the view you are seeing

So, I've recently inherited a large code base that is fairly obfuscated. When I navigate a page on my local machine is there any way to determine which template/view is actually being called to create the view that I'm seeing at that moment?
I would like to get a better idea of where certain parts of the page are actually coming from, but the project is so large and disorganized that going through present templates is simply not feasible.
Is there any nice way to get around this? Worth mentioning that the defined urls all seem to be poorly written, obfuscated regex, (not to mention incredibly long) so direct examination of the urls file is not extremely feasible.
When I try to run resolve on the url of the page I'm trying to view I get a 404, and I'm not really sure where to progress from there, since the page clearly works.
Any help would be greatly appreciated.

Personnaly I use this : https://github.com/django-debug-toolbar/django-debug-toolbar
The Django Debug Toolbar is a configurable set of panels that display
various debug information about the current request/response and when
clicked, display more details about the panel's content.
Currently, the following panels have been written and are working:
Django version
Request timer
A list of settings in settings.py
Common HTTP headers
GET/POST/cookie/session variable display
Templates and context used, and their template paths
SQL queries including time to execute and links to EXPLAIN each query
List of signals, their args and receivers
Logging output via Python's built-in logging, or via the logbook module
There is also one Django management command currently:
debugsqlshell: Outputs the SQL that gets executed as you work in the Python interactive shell. (See example below)
If you have ideas for other panels please let us know.
Note: The Debug Toolbar only works on Django 1.3 and newer.
0 code to add, only a few minor changes to settings.py
You will get what you want and even more.

Blank responses from Django runserver when checking user permissions

I have a similar problem to those listed in
Django produces blank pages when POST data is sent and Models are accessed
and
Nginx connection reset, response from uWsgi lost
Here is one of the views in question:
#transaction.commit_on_success
#occ_update
#checks_status
def hold(request):
if not request.user.has_perm('orders.hold'):
return error_response_rollback(NO_PERMISSION_MSG % "hold orders")
order = Order.objects.get(pk=request.POST.get('pk'))
occ_revision = int(request.POST.get('occ_revision'))
agent = Agent.get_agent(request.user)
action = Action(agent=agent, type='hold_order',
comments=request.POST.get('comments'))
action.save()
order.hold(action, occ_revision)
return ok_response_commit("Order held successfully.")
error_response_rollback rolls back the transaction and returns an HttpResponse with JSON as its contents.
I am adding permission checking to many of my views in my application and when the user does not have the correct permission, a blank response is returned.
However like the questions referenced above, if you put a
print request
or
request.POST
statement BEFORE the permission check, the NO_PERMISSION_MSG JSON string is returned to the browser correctly every time (error_response_rollback returns an HttpResponse object with JSON in it.)
You get blank responses when you check permissions before the "print request" and they do not have the correct permissions.
You do NOT get blank responses when:
the user has the correct permissions
a "print request" statement is before any permission check
you use Firefox at any point.
The #occ_update and #checks_status decorators just catch exceptions. These problems occur with and without them present.
I'm developing in Chrome and none of this is an issue in Firefox.
One page I found suggested overloading the WSGIRequest object to read the request before it is passed to the view but this seems icky to me and I'd rather find out the real solution.
Does anyone know of any fixes/settings to the runserver command to help this issue without hacking on the request? My users are primarily using Chrome so I'd prefer to keep using it... we'll see. Currently developing in Windows using Django 1.3.1
One option I have considered is making another manage.py command to handle this but that, too, seems icky.
Thanks
Update:
I have been able to re-organize my code so that any permission checks happen after some bit of data is read from the POST. This seems to have eliminated any symptoms of this problem. It's still not ideal but it is a good alternative to inserting middleware to read the post. and won't always be possible in all applications.
Please comment if you have a similar situation and just can't figure it out.

As saying in the second link in your post, especially http://forum.nginx.org/read.php?2,196581 : when you works w/ Nginx and uWSGI and get a non-empty POST, always read the request.POST before return an HttpResponse. The reason is described in the link.
You don't have to override an handler, just put the request.POST line before the return code, or inside some decorator or middleware.
I encountered this issue for production site half a year ago and put the line in a middleware to solve it.

How to see current context when debugging template errors?

I am getting a template error during rendering, which I think would be easy to fix if I could just see what's in the context that is passed into the template that is being rendered. Django's debug error page provides a lot of information, but I'm not seeing my context anywhere. Am I missing something? Also, I am using Django-debug-toolbar, but that only seems to come up if the page successfully renders. Not being able to see the contents of the context that is passed to the template makes debugging some types of template errors hard! What do I need to do to be able to see it in this scenario? (Note that I'm not asking for a fix to my specific error, which is why I'm not providing more information about it).

From the comments:
I think you need to walk up the stacktrace (in the django debug page) to actually see your context variables. I don't understand your problem exactly. If I have a template error I can inspect my context somewhere in the traceback.
Yes, setting a "breakpoint" in django can sometimes mean just inserting a non-defined variable at the point you want to inspect. The last entry in the traceback is usually the one for this variable. It will give you all context details in the traceback of the debug page.

The easiest way to do this is with the Django Debug Toolbar. it will give you a popup tab on the right hand side of your screen that you can use to inspect various things about the current page's request. Things like SQL statements, versions, logging, and all the templates that were used to render the page, and the context available to each of them.

Pass errors in Django using HttpResponseRedirect

I know that HttpResponseRedirect only takes one parameter, a URL. But there are cases when I want to redirect with an error message to display.
I was reading this post: How to pass information using an HTTP redirect (in Django) and there were a lot of good suggestions. I don't really want to use a library that I don't know how works. I don't want to rely on messages which, according to the Django docs, is going to be removed. I thought about using sessions. I also like the idea of passing it in a URL, something like:
return HttpResponseRedirect('/someurl/?error=1')
and then having some map from error code to message. Is it good practice to have a global map-like structure which hard codes in these error messages or is there a better way?
Or should I just use a session
EDIT: I got it working using a session. Is that a good practice to put things like this in the session?

You are right about the auth messages. They are deprecated but as the docs suggest you should use the django messages framework instead, which I think is the exact soultion for your case.

Pylons - catching errors before redirect to document/error for logging

I want to log 404 and 500 errors in a pylons app before they redirect to my custom error message (/error/document).
My problem is that since Pylons does the redirect, I am unable to determine the page on which the error occurred inside the error controller. So without building a parser for the paster.log I don't know a good way to selectively log just the few relevant pieces of data I want: url, referring page, and stack trace.
Ideally, I would like to access the page the error occurred on, the referring page, as well as the full stack trace and throw that into a couchdb for some quick and easy reports.

For custom error handling i think you should look at ErrorHandler and StatusCodeRedirect (from pylons.middleware) and maybe make your own class based on them?

You can get the original Pylons request and response object from the current request. From there, you can grab the data you need:
request = self._py_object.request.environ['pylons.original_request']
response = self._py_object.request.environ['pylons.original_response']
url = request.environ.get("PATH_INFO")
I'm not sure how to get the referring page or what stack trace you want, but I'm willing to bet it's in there somewhere.