{"id":75722,"date":"2020-01-20T11:52:26","date_gmt":"2020-01-20T06:22:26","guid":{"rendered":"https:\/\/www.vskills.in\/certification\/tutorial\/?p=75722"},"modified":"2024-04-12T14:17:15","modified_gmt":"2024-04-12T08:47:15","slug":"requestcontext-and-context-processors-2","status":"publish","type":"page","link":"https:\/\/www.vskills.in\/certification\/tutorial\/requestcontext-and-context-processors-2\/","title":{"rendered":"RequestContext and Context Processors"},"content":{"rendered":"

When rendering a template, you need a context. This can be an instance of django.template.Context, but Django also comes with a subclass, django.template.RequestContext, that acts slightly differently.<\/p>\n

RequestContext adds a bunch of variables to your template context by default \u2013 things like the HttpRequest object or information about the currently logged-in user.<\/p>\n

The render() shortcut creates a RequestContext unless it\u2019s passed a different context instance explicitly. For example, consider these two views:<\/p>\n

from django.template import loader, Context<\/p>\n

def view_1(request):
\n# …
\nt = loader.get_template(‘template1.html’)
\nc = Context({
\n‘app’: ‘My app’,
\n‘user’: request.user,
\n‘ip_address’: request.META[‘REMOTE_ADDR’],
\n‘message’: ‘I am view 1.’
\n})
\nreturn t.render(c)<\/p>\n

def view_2(request):
\n# …
\nt = loader.get_template(‘template2.html’)
\nc = Context({
\n‘app’: ‘My app’,
\n‘user’: request.user,
\n‘ip_address’: request.META[‘REMOTE_ADDR’],
\n‘message’: ‘I am the second view.’
\n})
\nreturn t.render(c)<\/p>\n

(Note that I\u2019m deliberately not using the render() shortcut in these examples \u2013 we\u2019re manually loading the templates, constructing the context objects and rendering the templates. I\u2019m \u201cspelling out\u201d all of the steps for the purpose of clarity.)<\/p>\n

Each view passes the same three variables \u2013 app, user and ip_address \u2013 to its template. Wouldn\u2019t it be nice if we could remove that redundancy? RequestContext and context processors were created to solve this problem. Context processors let you specify a number of variables that get set in each context automatically \u2013 without you having to specify the variables in each render() call.<\/p>\n

The catch is that you have to use RequestContext instead of Context when you render a template. The most low-level way of using context processors is to create some processors and pass them to RequestContext. Here\u2019s how the above example could be written with context processors:<\/p>\n

from django.template import loader, RequestContext<\/p>\n

def custom_proc(request):
\n# A context processor that provides ‘app’, ‘user’ and ‘ip_address’.
\nreturn {
\n‘app’: ‘My app’,
\n‘user’: request.user,
\n‘ip_address’: request.META[‘REMOTE_ADDR’]\n}<\/p>\n

def view_1(request):
\n# …
\nt = loader.get_template(‘template1.html’)
\nc = RequestContext(request,
\n{‘message’: ‘I am view 1.’},
\nprocessors=[custom_proc])
\nreturn t.render(c)<\/p>\n

def view_2(request):
\n# …
\nt = loader.get_template(‘template2.html’)
\nc = RequestContext(request,
\n{‘message’: ‘I am the second view.’},
\nprocessors=[custom_proc])
\nreturn t.render(c)<\/p>\n

Let\u2019s step through this code:<\/p>\n