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

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