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

This commit is contained in:
Tim Graham 2015-12-22 10:21:24 -05:00
parent edf3b88f1a
commit 4d83b0163e
17 changed files with 51 additions and 125 deletions

View File

@ -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:

View File

@ -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):
"""

View File

@ -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,

View File

@ -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:

View File

@ -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::

View File

@ -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>`

View File

@ -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

View File

@ -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.

View File

@ -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

View File

@ -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,
})

View File

@ -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.

View File

@ -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.

View File

@ -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
===========================

View File

@ -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``
============

View File

@ -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

View File

@ -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::

View File

@ -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: