22π
β
The RequestContext
initializer will run any context processors listed in the settings file, but it also takes a list of additional processors to run. Any general purpose context processors can be put in settings.py and more specific ones can be added to the RequestContext
on a case-by-case basis.
Leave RequestContext
out altogether to not run any context processors.
# want context processors listed in settings.py as well as some more specific ones
return render_to_response('template.html', {'foo':'bar'}, context_instance=RequestContext(request, processors = extra_processors))
# want only context processors listed in settings.py
return render_to_response('template.html', {'foo':'bar'}, context_instance=RequestContext(request))
# no context processors
return render_to_response('template.html', {'foo':'bar'})
π€Baldu
1π
You can filter out which views actually use context processors by only passing RequestContext(request)
only to those which need it, e.g.:
# want context processors
return render_to_response('template.html', {'foo':'bar'}, context_instance=RequestContext(request))
# no context processors
return render_to_response('template.html', {'foo':'bar'})
π€tghw
- How to specify which eth interface Django test server should listen on?
- "Returning to that page might cause any action you took to be repeated" β Django
- Deploying django in a production server
- Django signals, how to use "instance"
Source:stackexchange.com