Browse Source

Fixed #25969 -- Replaced render_to_response() with render() in docs examples.

Tim Graham 9 years ago
parent
commit
4d83b0163e

+ 1 - 1
django/contrib/gis/maps/google/__init__.py

@@ -7,7 +7,7 @@
   Example:
 
    * In the view:
-      return render_to_response('template.html', {'google' : GoogleMap(key="abcdefg")})
+      return render(request, 'template.html', {'google': GoogleMap(key="abcdefg")})
 
    * In the template:
 

+ 8 - 6
django/contrib/gis/maps/google/overlays.py

@@ -24,7 +24,7 @@ class GEvent(object):
 
     Example:
 
-      from django.shortcuts import render_to_response
+      from django.shortcuts import render
       from django.contrib.gis.maps.google import GoogleMap, GEvent, GPolyline
 
       def sample_request(request):
@@ -32,8 +32,9 @@ class GEvent(object):
           event = GEvent('click',
             'function() { location.href = "http://www.google.com"}')
           polyline.add_event(event)
-          return render_to_response('mytemplate.html',
-          {'google' : GoogleMap(polylines=[polyline])})
+          return render(request, 'mytemplate.html', {
+              'google': GoogleMap(polylines=[polyline]),
+          })
     """
 
     def __init__(self, event, action):
@@ -271,7 +272,7 @@ class GMarker(GOverlayBase):
 
     Example:
 
-      from django.shortcuts import render_to_response
+      from django.shortcuts import render
       from django.contrib.gis.maps.google.overlays import GMarker, GEvent
 
       def sample_request(request):
@@ -279,8 +280,9 @@ class GMarker(GOverlayBase):
           event = GEvent('click',
                          'function() { location.href = "http://www.google.com"}')
           marker.add_event(event)
-          return render_to_response('mytemplate.html',
-                 {'google' : GoogleMap(markers=[marker])})
+          return render(request, 'mytemplate.html', {
+              'google': GoogleMap(markers=[marker]),
+          })
     """
     def __init__(self, geom, title=None, draggable=False, icon=None):
         """

+ 2 - 2
docs/internals/deprecation.txt

@@ -553,8 +553,8 @@ details on these changes.
   :class:`~django.template.response.SimpleTemplateResponse`, and
   :class:`~django.template.response.TemplateResponse`, will be removed.
   ``content_type`` should be used instead. This also applies to the
-  :func:`~django.shortcuts.render_to_response` shortcut and
-  the sitemap views, :func:`~django.contrib.sitemaps.views.index` and
+  ``render_to_response()`` shortcut and the sitemap views,
+  :func:`~django.contrib.sitemaps.views.index` and
   :func:`~django.contrib.sitemaps.views.sitemap`.
 
 * When :class:`~django.http.HttpResponse` is instantiated with an iterator,

+ 5 - 25
docs/ref/csrf.txt

@@ -45,31 +45,11 @@ To take advantage of CSRF protection in your views, follow these steps:
    This should not be done for POST forms that target external URLs, since
    that would cause the CSRF token to be leaked, leading to a vulnerability.
 
-3. In the corresponding view functions, ensure that the
-   ``'django.template.context_processors.csrf'`` context processor is
-   being used. Usually, this can be done in one of two ways:
-
-   1. Use RequestContext, which always uses
-      ``'django.template.context_processors.csrf'`` (no matter what template
-      context processors are configured in the :setting:`TEMPLATES` setting).
-      If you are using generic views or contrib apps, you are covered already,
-      since these apps use RequestContext throughout.
-
-   2. Manually import and use the processor to generate the CSRF token and
-      add it to the template context. e.g.::
-
-          from django.shortcuts import render_to_response
-          from django.template.context_processors import csrf
-
-          def my_view(request):
-              c = {}
-              c.update(csrf(request))
-              # ... view code here
-              return render_to_response("a_template.html", c)
-
-      You may want to write your own
-      :func:`~django.shortcuts.render_to_response()` wrapper that takes care
-      of this step for you.
+3. In the corresponding view functions, ensure that
+   :class:`~django.template.RequestContext` is used to render the response so
+   that ``{% csrf_token %}`` will work properly. If you're using the
+   :func:`~django.shortcuts.render` function, generic views, or contrib apps,
+   you are covered already since these all use ``RequestContext``.
 
 .. _csrf-ajax:
 

+ 1 - 2
docs/ref/template-response.txt

@@ -283,8 +283,7 @@ Using TemplateResponse and SimpleTemplateResponse
 
 A :class:`TemplateResponse` object can be used anywhere that a normal
 :class:`django.http.HttpResponse` can be used. It can also be used as an
-alternative to calling :func:`~django.shortcuts.render()` or
-:func:`~django.shortcuts.render_to_response()`.
+alternative to calling :func:`~django.shortcuts.render()`.
 
 For example, the following simple view returns a :class:`TemplateResponse`
 with a simple template and a context containing a queryset::

+ 1 - 1
docs/releases/1.3.txt

@@ -321,7 +321,7 @@ requests. These include:
   template tags that require access to template context.
 
 * A new :meth:`~django.shortcuts.render()` shortcut -- an alternative
-  to :meth:`~django.shortcuts.render_to_response()` providing a
+  to ``django.shortcuts.render_to_response()`` providing a
   :class:`~django.template.RequestContext` by default.
 
 * Support for combining :class:`F expressions <django.db.models.F>`

+ 2 - 3
docs/releases/1.7.txt

@@ -853,7 +853,7 @@ Templates
   * :func:`django.template.loader.get_template()`
   * :func:`django.template.loader.select_template()`
   * :func:`django.shortcuts.render()`
-  * :func:`django.shortcuts.render_to_response()`
+  * ``django.shortcuts.render_to_response()``
 
 * The :tfilter:`time` filter now accepts timezone-related :ref:`format
   specifiers <date-and-time-formatting-specifiers>` ``'e'``, ``'O'`` , ``'T'``
@@ -1824,8 +1824,7 @@ removed in Django 1.7 (please see the
 * :class:`~django.http.HttpResponse`,
   :class:`~django.template.response.SimpleTemplateResponse`,
   :class:`~django.template.response.TemplateResponse`,
-  :func:`~django.shortcuts.render_to_response`,
-  :func:`~django.contrib.sitemaps.views.index`, and
+  ``render_to_response()``, :func:`~django.contrib.sitemaps.views.index`, and
   :func:`~django.contrib.sitemaps.views.sitemap` no longer take a ``mimetype``
   argument
 

+ 1 - 1
docs/releases/1.8.txt

@@ -1578,7 +1578,7 @@ The following functions will no longer accept a ``dirs`` parameter to override
 * :func:`django.template.loader.get_template()`
 * :func:`django.template.loader.select_template()`
 * :func:`django.shortcuts.render()`
-* :func:`django.shortcuts.render_to_response()`
+* ``django.shortcuts.render_to_response()``
 
 The parameter didn't work consistently across different template loaders and
 didn't work for included templates.

+ 2 - 1
docs/topics/cache.txt

@@ -1114,11 +1114,12 @@ The headers you pass to ``vary_on_headers`` are not case sensitive;
 You can also use a helper function, :func:`django.utils.cache.patch_vary_headers`,
 directly. This function sets, or adds to, the ``Vary header``. For example::
 
+    from django.shortcuts import render
     from django.utils.cache import patch_vary_headers
 
     def my_view(request):
         # ...
-        response = render_to_response('template_name', context)
+        response = render(request, 'template_name', context)
         patch_vary_headers(response, ['Cookie'])
         return response
 

+ 4 - 4
docs/topics/forms/formsets.txt

@@ -582,7 +582,7 @@ The only thing you will want to be aware of is making sure to use the
 management form inside the template. Let's look at a sample view::
 
     from django.forms import formset_factory
-    from django.shortcuts import render_to_response
+    from django.shortcuts import render
     from myapp.forms import ArticleForm
 
     def manage_articles(request):
@@ -594,7 +594,7 @@ management form inside the template. Let's look at a sample view::
                 pass
         else:
             formset = ArticleFormSet()
-        return render_to_response('manage_articles.html', {'formset': formset})
+        return render(request, 'manage_articles.html', {'formset': formset})
 
 The ``manage_articles.html`` template might look like this:
 
@@ -659,7 +659,7 @@ more than one formset to be sent to a view without name clashing. Lets take
 a look at how this might be accomplished::
 
     from django.forms import formset_factory
-    from django.shortcuts import render_to_response
+    from django.shortcuts import render
     from myapp.forms import ArticleForm, BookForm
 
     def manage_articles(request):
@@ -674,7 +674,7 @@ a look at how this might be accomplished::
         else:
             article_formset = ArticleFormSet(prefix='articles')
             book_formset = BookFormSet(prefix='books')
-        return render_to_response('manage_articles.html', {
+        return render(request, 'manage_articles.html', {
             'article_formset': article_formset,
             'book_formset': book_formset,
         })

+ 5 - 11
docs/topics/forms/modelforms.txt

@@ -942,7 +942,7 @@ Model formsets are very similar to formsets. Let's say we want to present a
 formset to edit ``Author`` model instances::
 
     from django.forms import modelformset_factory
-    from django.shortcuts import render_to_response
+    from django.shortcuts import render
     from myapp.models import Author
 
     def manage_authors(request):
@@ -954,9 +954,7 @@ formset to edit ``Author`` model instances::
                 # do something.
         else:
             formset = AuthorFormSet()
-        return render_to_response("manage_authors.html", {
-            "formset": formset,
-        })
+        return render(request, 'manage_authors.html', {'formset': formset})
 
 As you can see, the view logic of a model formset isn't drastically different
 than that of a "normal" formset. The only difference is that we call
@@ -1010,7 +1008,7 @@ As stated earlier, you can override the default queryset used by the model
 formset::
 
     from django.forms import modelformset_factory
-    from django.shortcuts import render_to_response
+    from django.shortcuts import render
     from myapp.models import Author
 
     def manage_authors(request):
@@ -1023,9 +1021,7 @@ formset::
                 # Do something.
         else:
             formset = AuthorFormSet(queryset=Author.objects.filter(name__startswith='O'))
-        return render_to_response("manage_authors.html", {
-            "formset": formset,
-        })
+        return render(request, 'manage_authors.html", {'formset': formset})
 
 Note that we pass the ``queryset`` argument in both the ``POST`` and ``GET``
 cases in this example.
@@ -1201,9 +1197,7 @@ of a model. Here's how you can do that::
                 return HttpResponseRedirect(author.get_absolute_url())
         else:
             formset = BookInlineFormSet(instance=author)
-        return render_to_response("manage_books.html", {
-            "formset": formset,
-        })
+        return render(request, 'manage_books.html', {'formset': formset})
 
 Notice how we pass ``instance`` in both the ``POST`` and ``GET`` cases.
 

+ 2 - 2
docs/topics/http/file-uploads.txt

@@ -45,7 +45,7 @@ form as described in :ref:`binding-uploaded-files`. This would look
 something like::
 
     from django.http import HttpResponseRedirect
-    from django.shortcuts import render_to_response
+    from django.shortcuts import render
     from .forms import UploadFileForm
 
     # Imaginary function to handle an uploaded file.
@@ -59,7 +59,7 @@ something like::
                 return HttpResponseRedirect('/success/url/')
         else:
             form = UploadFileForm()
-        return render_to_response('upload.html', {'form': form})
+        return render(request, 'upload.html', {'form': form})
 
 Notice that we have to pass :attr:`request.FILES <django.http.HttpRequest.FILES>`
 into the form's constructor; this is how file data gets bound into a form.

+ 4 - 1
docs/topics/http/sessions.txt

@@ -451,6 +451,9 @@ yourself. Do this after you've verified that the test cookie worked.
 
 Here's a typical usage example::
 
+    from django.http import HttpResponse
+    from django.shortcuts import render
+
     def login(request):
         if request.method == 'POST':
             if request.session.test_cookie_worked():
@@ -459,7 +462,7 @@ Here's a typical usage example::
             else:
                 return HttpResponse("Please enable cookies and try again.")
         request.session.set_test_cookie()
-        return render_to_response('foo/login_form.html')
+        return render(request, 'foo/login_form.html')
 
 Using sessions out of views
 ===========================

+ 7 - 59
docs/topics/http/shortcuts.txt

@@ -20,9 +20,6 @@ introduce controlled coupling for convenience's sake.
    Combines a given template with a given context dictionary and returns an
    :class:`~django.http.HttpResponse` object with that rendered text.
 
-   :func:`render()` is the same as a call to :func:`render_to_response()` but
-   it also makes the current request available in the template.
-
    Django does not provide a shortcut function which returns a
    :class:`~django.template.response.TemplateResponse` because the constructor
    of :class:`~django.template.response.TemplateResponse` offers the same level
@@ -35,7 +32,10 @@ Required arguments
     The request object used to generate this response.
 
 ``template_name``
-    The full name of a template to use or sequence of template names.
+    The full name of a template to use or sequence of template names. If a
+    sequence is given, the first template that exists will be used. See the
+    :ref:`template loading documentation <template-loading>` for more
+    information on how templates are found.
 
 Optional arguments
 ------------------
@@ -86,61 +86,9 @@ This example is equivalent to::
 
 .. function:: render_to_response(template_name, context=None, content_type=None, status=None, using=None)
 
-   Renders a given template with a given context dictionary and returns an
-   :class:`~django.http.HttpResponse` object with that rendered text.
-
-Required arguments
-------------------
-
-``template_name``
-    The full name of a template to use or sequence of template names. If a
-    sequence is given, the first template that exists will be used. See the
-    :ref:`template loading documentation <template-loading>` for more
-    information on how templates are found.
-
-Optional arguments
-------------------
-
-``context``
-    A dictionary of values to add to the template context. By default, this
-    is an empty dictionary. If a value in the dictionary is callable, the
-    view will call it just before rendering the template.
-
-``content_type``
-    The MIME type to use for the resulting document. Defaults to the value of
-    the :setting:`DEFAULT_CONTENT_TYPE` setting.
-
-``status``
-    The status code for the response. Defaults to ``200``.
-
-``using``
-    The :setting:`NAME <TEMPLATES-NAME>` of a template engine to use for
-    loading the template.
-
-Example
--------
-
-The following example renders the template ``myapp/index.html`` with the
-MIME type :mimetype:`application/xhtml+xml`::
-
-    from django.shortcuts import render_to_response
-
-    def my_view(request):
-        # View code here...
-        return render_to_response('myapp/index.html', {"foo": "bar"},
-            content_type="application/xhtml+xml")
-
-This example is equivalent to::
-
-    from django.http import HttpResponse
-    from django.template import Context, loader
-
-    def my_view(request):
-        # View code here...
-        t = loader.get_template('myapp/index.html')
-        c = Context({'foo': 'bar'})
-        return HttpResponse(t.render(c),
-            content_type="application/xhtml+xml")
+   This function preceded the introduction of :func:`render` and works
+   similarly except that it doesn't making the ``request`` available in the
+   response. It's not recommended and is likely to be deprecated in the future.
 
 ``redirect``
 ============

+ 2 - 2
docs/topics/http/views.txt

@@ -112,7 +112,7 @@ standard error page for your application, along with an HTTP error code 404.
 Example usage::
 
     from django.http import Http404
-    from django.shortcuts import render_to_response
+    from django.shortcuts import render
     from polls.models import Poll
 
     def detail(request, poll_id):
@@ -120,7 +120,7 @@ Example usage::
             p = Poll.objects.get(pk=poll_id)
         except Poll.DoesNotExist:
             raise Http404("Poll does not exist")
-        return render_to_response('polls/detail.html', {'poll': p})
+        return render(request, 'polls/detail.html', {'poll': p})
 
 In order to show customized HTML when Django returns a 404, you can create an
 HTML template named ``404.html`` and place it in the top level of your

+ 2 - 1
docs/topics/pagination.txt

@@ -86,6 +86,7 @@ show how you can display the results. This example assumes you have a
 The view function looks like this::
 
     from django.core.paginator import Paginator, EmptyPage, PageNotAnInteger
+    from django.shortcuts import render
 
     def listing(request):
         contact_list = Contacts.objects.all()
@@ -101,7 +102,7 @@ The view function looks like this::
             # If page is out of range (e.g. 9999), deliver last page of results.
             contacts = paginator.page(paginator.num_pages)
 
-        return render_to_response('list.html', {"contacts": contacts})
+        return render(request, 'list.html', {'contacts': contacts})
 
 In the template :file:`list.html`, you'll want to include navigation between
 pages along with any interesting information from the objects themselves::

+ 2 - 3
docs/topics/templates.txt

@@ -256,9 +256,8 @@ templates, Django provides a shortcut function which automates the process.
         An optional :class:`~django.http.HttpRequest` that will be available
         during the template's rendering process.
 
-See also the :func:`~django.shortcuts.render()` and
-:func:`~django.shortcuts.render_to_response()` shortcuts, which call
-:func:`render_to_string()` and feed the result into an
+See also the :func:`~django.shortcuts.render()` shortcut which calls
+:func:`render_to_string()` and feeds the result into an
 :class:`~django.http.HttpResponse` suitable for returning from a view.
 
 Finally, you can use configured engines directly: