Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

replace render_to_response with render

Replaced the render_to_response shortcut with render everywhere because
newer django code tends not to use render_to_response at all. Also
updated text where it refered to render_to_response arguments and the
use of RequestContext with render.
  • Loading branch information...
commit a4724d5cc5aa0357fd67de0248792770ff85387a 1 parent c1cb41f
RaphaelKimmig authored October 20, 2012
2  appendixG.rst
Source Rendered
@@ -463,7 +463,7 @@ Here's an example::
463 463
             p = Poll.objects.get(pk=poll_id)
464 464
         except Poll.DoesNotExist:
465 465
             raise Http404
466  
-        return render_to_response('polls/detail.html', {'poll': p})
  466
+        return render(request, 'polls/detail.html', {'poll': p})
467 467
 
468 468
 In order to use the ``Http404`` exception to its fullest, you should create a
469 469
 template that is displayed when a 404 error is raised. This template should be
4  chapter01.rst
Source Rendered
@@ -132,12 +132,12 @@ an HTML template (``latest_books.html``)::
132 132
 
133 133
     # views.py (the business logic)
134 134
 
135  
-    from django.shortcuts import render_to_response
  135
+    from django.shortcuts import render
136 136
     from models import Book
137 137
 
138 138
     def latest_books(request):
139 139
         book_list = Book.objects.order_by('-pub_date')[:10]
140  
-        return render_to_response('latest_books.html', {'book_list': book_list})
  140
+        return render(request, 'latest_books.html', {'book_list': book_list})
141 141
 
142 142
 
143 143
     # urls.py (the URL configuration)
30  chapter04.rst
Source Rendered
@@ -1252,7 +1252,7 @@ directory using the following template code::
1252 1252
 Refresh the page in your Web browser, and you should see the fully rendered
1253 1253
 page.
1254 1254
 
1255  
-render_to_response()
  1255
+render()
1256 1256
 --------------------
1257 1257
 
1258 1258
 We've shown you how to load a template, fill a ``Context`` and return an
@@ -1263,39 +1263,39 @@ things. Because this is such a common idiom, Django provides a shortcut that
1263 1263
 lets you load a template, render it and return an ``HttpResponse`` -- all in
1264 1264
 one line of code.
1265 1265
 
1266  
-This shortcut is a function called ``render_to_response()``, which lives in the
  1266
+This shortcut is a function called ``render()``, which lives in the
1267 1267
 module ``django.shortcuts``. Most of the time, you'll be using
1268  
-``render_to_response()`` rather than loading templates and creating ``Context``
  1268
+``render()`` rather than loading templates and creating ``Context``
1269 1269
 and ``HttpResponse`` objects manually -- unless your employer judges your work
1270 1270
 by total lines of code written, that is.
1271 1271
 
1272 1272
 Here's the ongoing ``current_datetime`` example rewritten to use
1273  
-``render_to_response()``::
  1273
+``render()``::
1274 1274
 
1275  
-    from django.shortcuts import render_to_response
  1275
+    from django.shortcuts import render
1276 1276
     import datetime
1277 1277
 
1278 1278
     def current_datetime(request):
1279 1279
         now = datetime.datetime.now()
1280  
-        return render_to_response('current_datetime.html', {'current_date': now})
  1280
+        return render(request, 'current_datetime.html', {'current_date': now})
1281 1281
 
1282 1282
 What a difference! Let's step through the code changes:
1283 1283
 
1284 1284
 * We no longer have to import ``get_template``, ``Template``, ``Context``,
1285 1285
   or ``HttpResponse``. Instead, we import
1286  
-  ``django.shortcuts.render_to_response``. The ``import datetime`` remains.
  1286
+  ``django.shortcuts.render``. The ``import datetime`` remains.
1287 1287
 
1288 1288
 * Within the ``current_datetime`` function, we still calculate ``now``, but
1289 1289
   the template loading, context creation, template rendering, and
1290 1290
   ``HttpResponse`` creation are all taken care of by the
1291  
-  ``render_to_response()`` call. Because ``render_to_response()`` returns
  1291
+  ``render()`` call. Because ``render()`` returns
1292 1292
   an ``HttpResponse`` object, we can simply ``return`` that value in the
1293 1293
   view.
1294 1294
 
1295  
-The first argument to ``render_to_response()`` is the name of the template to
1296  
-use. The second argument, if given, should be a dictionary to use in creating a
1297  
-``Context`` for that template. If you don't provide a second argument,
1298  
-``render_to_response()`` will use an empty dictionary.
  1295
+The first argument to ``render()`` is the request, the second is the name of
  1296
+the template to use. The third argument, if given, should be a dictionary to
  1297
+use in creating a ``Context`` for that template. If you don't provide a third
  1298
+argument, ``render()`` will use an empty dictionary.
1299 1299
 
1300 1300
 Subdirectories in get_template()
1301 1301
 --------------------------------
@@ -1312,11 +1312,11 @@ the subdirectory name and a slash before the template name, like so::
1312 1312
 
1313 1313
     t = get_template('dateapp/current_datetime.html')
1314 1314
 
1315  
-Because ``render_to_response()`` is a small wrapper around ``get_template()``,
1316  
-you can do the same thing with the first argument to ``render_to_response()``,
  1315
+Because ``render()`` is a small wrapper around ``get_template()``,
  1316
+you can do the same thing with the second argument to ``render()``,
1317 1317
 like this::
1318 1318
 
1319  
-    return render_to_response('dateapp/current_datetime.html', {'current_date': now})
  1319
+    return render(request, 'dateapp/current_datetime.html', {'current_date': now})
1320 1320
 
1321 1321
 There's no limit to the depth of your subdirectory tree. Feel free to use
1322 1322
 as many subdirectories as you like.
8  chapter05.rst
Source Rendered
@@ -41,7 +41,7 @@ In this example view, we use the ``MySQLdb`` library (available via
41 41
 http://www.djangoproject.com/r/python-mysql/) to connect to a MySQL database,
42 42
 retrieve some records, and feed them to a template for display as a Web page::
43 43
 
44  
-    from django.shortcuts import render_to_response
  44
+    from django.shortcuts import render
45 45
     import MySQLdb
46 46
 
47 47
     def book_list(request):
@@ -50,7 +50,7 @@ retrieve some records, and feed them to a template for display as a Web page::
50 50
         cursor.execute('SELECT name FROM books ORDER BY name')
51 51
         names = [row[0] for row in cursor.fetchall()]
52 52
         db.close()
53  
-        return render_to_response('book_list.html', {'names': names})
  53
+        return render(request, 'book_list.html', {'names': names})
54 54
 
55 55
 .. SL Tested ok
56 56
 
@@ -77,12 +77,12 @@ As you might expect, Django's database layer aims to solve these problems.
77 77
 Here's a sneak preview of how the previous view can be rewritten using Django's
78 78
 database API::
79 79
 
80  
-    from django.shortcuts import render_to_response
  80
+    from django.shortcuts import render
81 81
     from mysite.books.models import Book
82 82
 
83 83
     def book_list(request):
84 84
         books = Book.objects.order_by('name')
85  
-        return render_to_response('book_list.html', {'books': books})
  85
+        return render(request, 'book_list.html', {'books': books})
86 86
 
87 87
 We'll explain this code a little later in the chapter. For now, just get a
88 88
 feel for how it looks.
42  chapter07.rst
Source Rendered
@@ -162,10 +162,10 @@ Generally, there are two parts to developing a form: the HTML user interface
162 162
 and the backend view code that processes the submitted data. The first part is
163 163
 easy; let's just set up a view that displays a search form::
164 164
 
165  
-    from django.shortcuts import render_to_response
  165
+    from django.shortcuts import render
166 166
 
167 167
     def search_form(request):
168  
-        return render_to_response('search_form.html')
  168
+        return render(request, 'search_form.html')
169 169
 
170 170
 As we learned in Chapter 3, this view can live anywhere on your Python path.
171 171
 For sake of argument, put it in ``books/views.py``.
@@ -278,14 +278,14 @@ Now that we've verified ``request.GET`` is being passed in properly, let's hook
278 278
 the user's search query into our book database (again, in ``views.py``)::
279 279
 
280 280
     from django.http import HttpResponse
281  
-    from django.shortcuts import render_to_response
  281
+    from django.shortcuts import render
282 282
     from mysite.books.models import Book
283 283
 
284 284
     def search(request):
285 285
         if 'q' in request.GET and request.GET['q']:
286 286
             q = request.GET['q']
287 287
             books = Book.objects.filter(title__icontains=q)
288  
-            return render_to_response('search_results.html',
  288
+            return render(request, 'search_results.html',
289 289
                 {'books': books, 'query': q})
290 290
         else:
291 291
             return HttpResponse('Please submit a search term.')
@@ -349,20 +349,20 @@ render the template again, like this:
349 349
 .. parsed-literal::
350 350
 
351 351
     from django.http import HttpResponse
352  
-    from django.shortcuts import render_to_response
  352
+    from django.shortcuts import render
353 353
     from mysite.books.models import Book
354 354
 
355 355
     def search_form(request):
356  
-        return render_to_response('search_form.html')
  356
+        return render(request, 'search_form.html')
357 357
 
358 358
     def search(request):
359 359
         if 'q' in request.GET and request.GET['q']:
360 360
             q = request.GET['q']
361 361
             books = Book.objects.filter(title__icontains=q)
362  
-            return render_to_response('search_results.html',
  362
+            return render(request, 'search_results.html',
363 363
                 {'books': books, 'query': q})
364 364
         else:
365  
-            **return render_to_response('search_form.html', {'error': True})**
  365
+            **return render(request, 'search_form.html', {'error': True})**
366 366
 
367 367
 (Note that we've included ``search_form()`` here so you can see both views in
368 368
 one place.)
@@ -411,9 +411,9 @@ parameters::
411 411
                 error = True
412 412
             else:
413 413
                 books = Book.objects.filter(title__icontains=q)
414  
-                return render_to_response('search_results.html',
  414
+                return render(request, 'search_results.html',
415 415
                     {'books': books, 'query': q})
416  
-        return render_to_response('search_form.html',
  416
+        return render(request, 'search_form.html',
417 417
             {'error': error})
418 418
 
419 419
 .. SL Tested ok
@@ -487,9 +487,9 @@ like this:
487 487
                 **error = True**
488 488
             else:
489 489
                 books = Book.objects.filter(title__icontains=q)
490  
-                return render_to_response('search_results.html',
  490
+                return render(request, 'search_results.html',
491 491
                     {'books': books, 'query': q})
492  
-        return render_to_response('search_form.html',
  492
+        return render(request, 'search_form.html',
493 493
             {'error': error})
494 494
 
495 495
 Now, if you try submitting a search query greater than 20 characters long,
@@ -537,9 +537,9 @@ how we might fix that:
537 537
                 **errors.append('Please enter at most 20 characters.')**
538 538
             else:
539 539
                 books = Book.objects.filter(title__icontains=q)
540  
-                return render_to_response('search_results.html',
  540
+                return render(request, 'search_results.html',
541 541
                     {'books': books, 'query': q})
542  
-        return render_to_response('search_form.html',
  542
+        return render(request, 'search_form.html',
543 543
             {**'errors': errors**})
544 544
 
545 545
 Then, we need make a small tweak to the ``search_form.html`` template to
@@ -623,7 +623,7 @@ this::
623 623
 
624 624
     from django.core.mail import send_mail
625 625
     from django.http import HttpResponseRedirect
626  
-    from django.shortcuts import render_to_response
  626
+    from django.shortcuts import render
627 627
 
628 628
     def contact(request):
629 629
         errors = []
@@ -642,7 +642,7 @@ this::
642 642
                     ['siteowner@example.com'],
643 643
                 )
644 644
                 return HttpResponseRedirect('/contact/thanks/')
645  
-        return render_to_response('contact_form.html',
  645
+        return render(request, 'contact_form.html',
646 646
             {'errors': errors})
647 647
 
648 648
 .. SL Tested ok (modulo email config and lack of thanks view)
@@ -696,7 +696,7 @@ A couple of new things are happening here:
696 696
   ``HttpResponseRedirect`` object. We'll leave the implementation of that
697 697
   "success" page up to you (it's a simple view/URLconf/template), but we
698 698
   should explain why we initiate a redirect instead of, for example, simply
699  
-  calling ``render_to_response()`` with a template right there.
  699
+  calling ``render()`` with a template right there.
700 700
 
701 701
   The reason: if a user hits "Refresh" on a page that was loaded via
702 702
   ``POST``, that request will be repeated. This can often lead to undesired
@@ -740,7 +740,7 @@ edit each HTML field to insert the proper value in the proper place:
740 740
                     ['siteowner@example.com'],
741 741
                 )
742 742
                 return HttpResponseRedirect('/contact/thanks/')
743  
-        return render_to_response('contact_form.html', {
  743
+        return render(request, 'contact_form.html', {
744 744
             'errors': errors,
745 745
             **'subject': request.POST.get('subject', ''),**
746 746
             **'message': request.POST.get('message', ''),**
@@ -957,7 +957,7 @@ Here's how we can rewrite ``contact()`` to use the forms framework::
957 957
 
958 958
     # views.py
959 959
 
960  
-    from django.shortcuts import render_to_response
  960
+    from django.shortcuts import render
961 961
     from mysite.contact.forms import ContactForm
962 962
 
963 963
     def contact(request):
@@ -974,7 +974,7 @@ Here's how we can rewrite ``contact()`` to use the forms framework::
974 974
                 return HttpResponseRedirect('/contact/thanks/')
975 975
         else:
976 976
             form = ContactForm()
977  
-        return render_to_response('contact_form.html', {'form': form})
  977
+        return render(request, 'contact_form.html', {'form': form})
978 978
 
979 979
     # contact_form.html
980 980
 
@@ -1081,7 +1081,7 @@ hurt.) To do this, we can use the ``initial`` argument when we create a
1081 1081
             form = ContactForm(
1082 1082
                 **initial={'subject': 'I love your site!'}**
1083 1083
             )
1084  
-        return render_to_response('contact_form.html', {'form': form})
  1084
+        return render(request, 'contact_form.html', {'form': form})
1085 1085
 
1086 1086
 .. SL Tested ok
1087 1087
 
42  chapter08.rst
Source Rendered
@@ -320,16 +320,16 @@ contents are identical except for the template they use::
320 320
 
321 321
     # views.py
322 322
 
323  
-    from django.shortcuts import render_to_response
  323
+    from django.shortcuts import render
324 324
     from mysite.models import MyModel
325 325
 
326 326
     def foo_view(request):
327 327
         m_list = MyModel.objects.filter(is_new=True)
328  
-        return render_to_response('template1.html', {'m_list': m_list})
  328
+        return render(request, 'template1.html', {'m_list': m_list})
329 329
 
330 330
     def bar_view(request):
331 331
         m_list = MyModel.objects.filter(is_new=True)
332  
-        return render_to_response('template2.html', {'m_list': m_list})
  332
+        return render(request, 'template2.html', {'m_list': m_list})
333 333
 
334 334
 We're repeating ourselves in this code, and that's inelegant. At first, you
335 335
 may think to remove the redundancy by using the same view for both URLs,
@@ -348,7 +348,7 @@ the view to determine the template, like so::
348 348
 
349 349
     # views.py
350 350
 
351  
-    from django.shortcuts import render_to_response
  351
+    from django.shortcuts import render
352 352
     from mysite.models import MyModel
353 353
 
354 354
     def foobar_view(request, url):
@@ -357,7 +357,7 @@ the view to determine the template, like so::
357 357
             template_name = 'template1.html'
358 358
         elif url == 'bar':
359 359
             template_name = 'template2.html'
360  
-        return render_to_response(template_name, {'m_list': m_list})
  360
+        return render(request, template_name, {'m_list': m_list})
361 361
 
362 362
 The problem with that solution, though, is that it couples your URLs to your
363 363
 code. If you decide to rename ``/foo/`` to ``/fooey/``, you'll have to remember
@@ -381,12 +381,12 @@ With this in mind, we can rewrite our ongoing example like this::
381 381
 
382 382
     # views.py
383 383
 
384  
-    from django.shortcuts import render_to_response
  384
+    from django.shortcuts import render
385 385
     from mysite.models import MyModel
386 386
 
387 387
     def foobar_view(request, template_name):
388 388
         m_list = MyModel.objects.filter(is_new=True)
389  
-        return render_to_response(template_name, {'m_list': m_list})
  389
+        return render(request, template_name, {'m_list': m_list})
390 390
 
391 391
 As you can see, the URLconf in this example specifies ``template_name`` in the
392 392
 URLconf. The view function treats it as just another parameter.
@@ -487,16 +487,16 @@ Take this code, for example::
487 487
 
488 488
     # views.py
489 489
 
490  
-    from django.shortcuts import render_to_response
  490
+    from django.shortcuts import render
491 491
     from mysite.models import Event, BlogEntry
492 492
 
493 493
     def event_list(request):
494 494
         obj_list = Event.objects.all()
495  
-        return render_to_response('mysite/event_list.html', {'event_list': obj_list})
  495
+        return render(request, 'mysite/event_list.html', {'event_list': obj_list})
496 496
 
497 497
     def entry_list(request):
498 498
         obj_list = BlogEntry.objects.all()
499  
-        return render_to_response('mysite/blogentry_list.html', {'entry_list': obj_list})
  499
+        return render(request, 'mysite/blogentry_list.html', {'entry_list': obj_list})
500 500
 
501 501
 The two views do essentially the same thing: they display a list of objects. So
502 502
 let's factor out the type of object they're displaying::
@@ -513,12 +513,12 @@ let's factor out the type of object they're displaying::
513 513
 
514 514
     # views.py
515 515
 
516  
-    from django.shortcuts import render_to_response
  516
+    from django.shortcuts import render
517 517
 
518 518
     def object_list(request, model):
519 519
         obj_list = model.objects.all()
520 520
         template_name = 'mysite/%s_list.html' % model.__name__.lower()
521  
-        return render_to_response(template_name, {'object_list': obj_list})
  521
+        return render(request, template_name, {'object_list': obj_list})
522 522
 
523 523
 With those small changes, we suddenly have a reusable, model-agnostic view!
524 524
 From now on, anytime we need a view that lists a set of objects, we can simply
@@ -562,7 +562,7 @@ A common bit of an application to make configurable is the template name::
562 562
 
563 563
     def my_view(request, template_name):
564 564
         var = do_something()
565  
-        return render_to_response(template_name, {'var': var})
  565
+        return render(request, template_name, {'var': var})
566 566
 
567 567
 Understanding Precedence of Captured Values vs. Extra Options
568 568
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -633,7 +633,7 @@ value for ``template_name``::
633 633
 
634 634
     def my_view(request, template_name='mysite/my_view.html'):
635 635
         var = do_something()
636  
-        return render_to_response(template_name, {'var': var})
  636
+        return render(request, template_name, {'var': var})
637 637
 
638 638
 .. SL Again wonder whether default should be unicode?
639 639
 
@@ -774,7 +774,7 @@ might build a nice way of doing that. Consider this URLconf/view layout::
774 774
     # views.py
775 775
 
776 776
     from django.http import Http404, HttpResponseRedirect
777  
-    from django.shortcuts import render_to_response
  777
+    from django.shortcuts import render
778 778
 
779 779
     def some_page(request):
780 780
         if request.method == 'POST':
@@ -782,7 +782,7 @@ might build a nice way of doing that. Consider this URLconf/view layout::
782 782
             return HttpResponseRedirect('/someurl/')
783 783
         elif request.method == 'GET':
784 784
             do_something_for_get()
785  
-            return render_to_response('page.html')
  785
+            return render(request, 'page.html')
786 786
         else:
787 787
             raise Http404()
788 788
 
@@ -800,7 +800,7 @@ this technique could help simplify our ``some_page()`` view::
800 800
     # views.py
801 801
 
802 802
     from django.http import Http404, HttpResponseRedirect
803  
-    from django.shortcuts import render_to_response
  803
+    from django.shortcuts import render
804 804
 
805 805
     def method_splitter(request, GET=None, POST=None):
806 806
         if request.method == 'GET' and GET is not None:
@@ -812,7 +812,7 @@ this technique could help simplify our ``some_page()`` view::
812 812
     def some_page_get(request):
813 813
         assert request.method == 'GET'
814 814
         do_something_for_get()
815  
-        return render_to_response('page.html')
  815
+        return render(request, 'page.html')
816 816
 
817 817
     def some_page_post(request):
818 818
         assert request.method == 'POST'
@@ -929,19 +929,19 @@ example::
929 929
         if not request.user.is_authenticated():
930 930
             return HttpResponseRedirect('/accounts/login/')
931 931
         # ...
932  
-        return render_to_response('template1.html')
  932
+        return render(request, 'template1.html')
933 933
 
934 934
     def my_view2(request):
935 935
         if not request.user.is_authenticated():
936 936
             return HttpResponseRedirect('/accounts/login/')
937 937
         # ...
938  
-        return render_to_response('template2.html')
  938
+        return render(request, 'template2.html')
939 939
 
940 940
     def my_view3(request):
941 941
         if not request.user.is_authenticated():
942 942
             return HttpResponseRedirect('/accounts/login/')
943 943
         # ...
944  
-        return render_to_response('template3.html')
  944
+        return render(request, 'template3.html')
945 945
 
946 946
 Here, each view starts by checking that ``request.user`` is authenticated
947 947
 -- that is, the current user has successfully logged into the site -- and
24  chapter09.rst
Source Rendered
@@ -62,12 +62,14 @@ simplicity.
62 62
 RequestContext and Context Processors
63 63
 =====================================
64 64
 
65  
-When rendering a template, you need a context. Usually this is an instance of
66  
-``django.template.Context``, but Django also comes with a special subclass,
  65
+When rendering a template, you need a context. This can be an instance of
  66
+``django.template.Context``, but Django also comes with a subclass,
67 67
 ``django.template.RequestContext``, that acts slightly differently.
68 68
 ``RequestContext`` adds a bunch of variables to your template context by
69 69
 default -- things like the ``HttpRequest`` object or information about the
70  
-currently logged-in user.
  70
+currently logged-in user. The ``render()`` shortcut creates a ``RequestContext`` 
  71
+unless it is passed a different context instance explicitly.
  72
+
71 73
 
72 74
 Use ``RequestContext`` when you don't want to have to specify the same set of
73 75
 variables in a series of templates. For example, consider these two views::
@@ -96,7 +98,7 @@ variables in a series of templates. For example, consider these two views::
96 98
         })
97 99
         return t.render(c)
98 100
 
99  
-(Note that we're deliberately *not* using the ``render_to_response()`` shortcut
  101
+(Note that we're deliberately *not* using the ``render()`` shortcut
100 102
 in these examples -- we're manually loading the templates, constructing the
101 103
 context objects and rendering the templates. We're "spelling out" all of the
102 104
 steps for the purpose of clarity.)
@@ -108,7 +110,7 @@ redundancy?
108 110
 ``RequestContext`` and **context processors** were created to solve this
109 111
 problem. Context processors let you specify a number of variables that get set
110 112
 in each context automatically -- without you having to specify the variables in
111  
-each ``render_to_response()`` call. The catch is that you have to use
  113
+each ``render()`` call. The catch is that you have to use
112 114
 ``RequestContext`` instead of ``Context`` when you render a template.
113 115
 
114 116
 The most low-level way of using context processors is to create some processors
@@ -161,15 +163,15 @@ Let's step through this code:
161 163
   variables it might need. In this example, the ``message`` template
162 164
   variable is set differently in each view.
163 165
 
164  
-In Chapter 4, we introduced the ``render_to_response()`` shortcut, which saves
  166
+In Chapter 4, we introduced the ``render()`` shortcut, which saves
165 167
 you from having to call ``loader.get_template()``, then create a ``Context``,
166 168
 then call the ``render()`` method on the template. In order to demonstrate the
167 169
 lower-level workings of context processors, the above examples didn't use
168  
-``render_to_response()``, . But it's possible -- and preferable -- to use
169  
-context processors with ``render_to_response()``. Do this with the
  170
+``render()``, . But it's possible -- and preferable -- to use
  171
+context processors with ``render()``. Do this with the
170 172
 ``context_instance`` argument, like so::
171 173
 
172  
-    from django.shortcuts import render_to_response
  174
+    from django.shortcuts import render
173 175
     from django.template import RequestContext
174 176
 
175 177
     def custom_proc(request):
@@ -182,13 +184,13 @@ context processors with ``render_to_response()``. Do this with the
182 184
 
183 185
     def view_1(request):
184 186
         # ...
185  
-        return render_to_response('template1.html',
  187
+        return render(request, 'template1.html',
186 188
             {'message': 'I am view 1.'},
187 189
             context_instance=RequestContext(request, processors=[custom_proc]))
188 190
 
189 191
     def view_2(request):
190 192
         # ...
191  
-        return render_to_response('template2.html',
  193
+        return render(request, 'template2.html',
192 194
             {'message': 'I am the second view.'},
193 195
             context_instance=RequestContext(request, processors=[custom_proc]))
194 196
 
22  chapter14.rst
Source Rendered
@@ -367,7 +367,7 @@ Here's a typical usage example::
367 367
 
368 368
         # If we didn't post, send the test cookie along with the login form.
369 369
         request.session.set_test_cookie()
370  
-        return render_to_response('foo/login_form.html')
  370
+        return render(request, 'foo/login_form.html')
371 371
 
372 372
 .. note::
373 373
 
@@ -837,7 +837,7 @@ or perhaps display an error message::
837 837
 
838 838
     def my_view(request):
839 839
         if not request.user.is_authenticated():
840  
-            return render_to_response('myapp/login_error.html')
  840
+            return render(request, 'myapp/login_error.html')
841 841
         # ...
842 842
 
843 843
 As a shortcut, you can use the convenient ``login_required`` decorator::
@@ -1031,7 +1031,7 @@ can use for this purpose, which we'll use in this example::
1031 1031
     from django import forms
1032 1032
     from django.contrib.auth.forms import UserCreationForm
1033 1033
     from django.http import HttpResponseRedirect
1034  
-    from django.shortcuts import render_to_response
  1034
+    from django.shortcuts import render
1035 1035
 
1036 1036
     def register(request):
1037 1037
         if request.method == 'POST':
@@ -1041,7 +1041,7 @@ can use for this purpose, which we'll use in this example::
1041 1041
                 return HttpResponseRedirect("/books/")
1042 1042
         else:
1043 1043
             form = UserCreationForm()
1044  
-        return render_to_response("registration/register.html", {
  1044
+        return render(request, "registration/register.html", {
1045 1045
             'form': form,
1046 1046
         })
1047 1047
 
@@ -1067,7 +1067,8 @@ Using Authentication Data in Templates
1067 1067
 --------------------------------------
1068 1068
 
1069 1069
 The current logged-in user and his or her permissions are made available in the
1070  
-template context when you use ``RequestContext`` (see Chapter 9).
  1070
+template context when you use the ``render()`` shortcut or explicitly use a
  1071
+``RequestContext`` (see Chapter 9).
1071 1072
 
1072 1073
 .. note::
1073 1074
 
@@ -1202,13 +1203,12 @@ playlist::
1202 1203
         request.user.message_set.create(
1203 1204
             message="Your playlist was added successfully."
1204 1205
         )
1205  
-        return render_to_response("playlists/create.html",
1206  
-            context_instance=RequestContext(request))
  1206
+        return render(request, "playlists/create.html")
1207 1207
 
1208  
-When you use ``RequestContext``, the current logged-in user and his or her
1209  
-messages are made available in the template context as the template variable
1210  
-``{{ messages }}``. Here's an example of template code that displays
1211  
-messages::
  1208
+When you use the ``render()`` shortcut or render a template with a
  1209
+``RequestContext``, the current logged-in user and his or her messages are made
  1210
+available in the template context as the template variable ``{{ messages }}``.
  1211
+Here's an example of template code that displays messages::
1212 1212
 
1213 1213
     {% if messages %}
1214 1214
     <ul>
2  chapter15.rst
Source Rendered
@@ -635,7 +635,7 @@ directly. This function sets, or adds to, the ``Vary header``. For example::
635 635
 
636 636
     def my_view(request):
637 637
         # ...
638  
-        response = render_to_response('template_name', context)
  638
+        response = render(request, 'template_name', context)
639 639
         patch_vary_headers(response, ['Cookie'])
640 640
         return response
641 641
 
4  chapter20.rst
Source Rendered
@@ -212,11 +212,11 @@ template system::
212 212
 
213 213
     # views.py
214 214
 
215  
-    from django.shortcuts import render_to_response
  215
+    from django.shortcuts import render
216 216
 
217 217
     def say_hello(request):
218 218
         name = request.GET.get('name', 'world')
219  
-        return render_to_response('hello.html', {'name': name})
  219
+        return render(request, 'hello.html', {'name': name})
220 220
 
221 221
     # hello.html
222 222
 

0 notes on commit a4724d5

Please sign in to comment.
Something went wrong with that request. Please try again.