mirror of https://github.com/django/django.git
Fixed #25969 -- Replaced render_to_response() with render() in docs examples.
This commit is contained in:
parent
edf3b88f1a
commit
4d83b0163e
|
@ -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:
|
||||
|
||||
|
|
|
@ -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):
|
||||
"""
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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::
|
||||
|
|
|
@ -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>`
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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,
|
||||
})
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
===========================
|
||||
|
|
|
@ -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``
|
||||
============
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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::
|
||||
|
|
|
@ -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:
|
||||
|
|
Loading…
Reference in New Issue