The package django.shortcuts
collects helper functions and classes that
“span” multiple levels of MVC. In other words, these functions/classes
introduce controlled coupling for convenience’s sake.
render
¶render
(request, template_name, context=None, context_instance=_context_instance_undefined, content_type=None, status=None, current_app=_current_app_undefined, dirs=_dirs_undefined, using=None)[source]¶Combines a given template with a given context dictionary and returns an
HttpResponse
object with that rendered text.
render()
is the same as a call to
render_to_response()
with a context_instance
argument that
forces the use of a RequestContext
.
Django does not provide a shortcut function which returns a
TemplateResponse
because the constructor
of TemplateResponse
offers the same level
of convenience as render()
.
request
template_name
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.
The context
argument used to be called dictionary
. That name
is deprecated in Django 1.8 and will be removed in Django 1.10.
context_instance
The context instance to render the template with. By default, the template
will be rendered with a RequestContext
instance (filled with values from
request
and context
).
Deprecated since version 1.8: The context_instance
argument is deprecated. Simply use context
.
content_type
DEFAULT_CONTENT_TYPE
setting.status
200
.current_app
A hint indicating which application contains the current view. See the namespaced URL resolution strategy for more information.
Deprecated since version 1.8: The current_app
argument is deprecated. Instead you should set
request.current_app
.
using
NAME
of a template engine to use for
loading the template.The using
parameter was added.
The dirs
parameter was added.
Deprecated since version 1.8: The dirs
parameter was deprecated.
The following example renders the template myapp/index.html
with the
MIME type application/xhtml+xml:
from django.shortcuts import render
def my_view(request):
# View code here...
return render(request, 'myapp/index.html', {"foo": "bar"},
content_type="application/xhtml+xml")
This example is equivalent to:
from django.http import HttpResponse
from django.template import loader
def my_view(request):
# View code here...
t = loader.get_template('myapp/index.html')
c = {'foo': 'bar'}
return HttpResponse(t.render(c, request),
content_type="application/xhtml+xml")
render_to_response
¶render_to_response
(template_name, context=None, context_instance=_context_instance_undefined, content_type=None, status=None, dirs=_dirs_undefined, using=None)[source]¶Renders a given template with a given context dictionary and returns an
HttpResponse
object with that rendered text.
template_name
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.
The context
argument used to be called dictionary
. That name
is deprecated in Django 1.8 and will be removed in Django 1.10.
context_instance
The context instance to render the template with. By default, the template
will be rendered with a Context
instance (filled
with values from context
). If you need to use context
processors, render the template with
a RequestContext
instance instead. Your code
might look something like this:
return render_to_response('my_template.html',
my_context,
context_instance=RequestContext(request))
Deprecated since version 1.8: The context_instance
argument is deprecated. Use the render()
function instead which always makes RequestContext
available.
content_type
DEFAULT_CONTENT_TYPE
setting.status
200
.using
NAME
of a template engine to use for
loading the template.The status
and using
parameters were added.
The dirs
parameter was added.
Deprecated since version 1.8: The dirs
parameter was deprecated.
The following example renders the template myapp/index.html
with the
MIME type 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")
redirect
¶redirect
(to, permanent=False, *args, **kwargs)[source]¶Returns an HttpResponseRedirect
to the appropriate URL
for the arguments passed.
The arguments could be:
get_absolute_url()
function will be called.urlresolvers.reverse
will be used to reverse-resolve the
name.By default issues a temporary redirect; pass permanent=True
to issue a
permanent redirect.
The ability to use relative URLs was added.
You can use the redirect()
function in a number of ways.
By passing some object; that object’s
get_absolute_url()
method will be called
to figure out the redirect URL:
from django.shortcuts import redirect
def my_view(request):
...
object = MyModel.objects.get(...)
return redirect(object)
By passing the name of a view and optionally some positional or
keyword arguments; the URL will be reverse resolved using the
reverse()
method:
def my_view(request):
...
return redirect('some-view-name', foo='bar')
By passing a hardcoded URL to redirect to:
def my_view(request):
...
return redirect('/some/url/')
This also works with full URLs:
def my_view(request):
...
return redirect('http://example.com/')
By default, redirect()
returns a temporary redirect. All of the above
forms accept a permanent
argument; if set to True
a permanent redirect
will be returned:
def my_view(request):
...
object = MyModel.objects.get(...)
return redirect(object, permanent=True)
get_object_or_404
¶get_object_or_404
(klass, *args, **kwargs)[source]¶Calls get()
on a given model manager,
but it raises Http404
instead of the model’s
DoesNotExist
exception.
The following example gets the object with the primary key of 1 from
MyModel
:
from django.shortcuts import get_object_or_404
def my_view(request):
my_object = get_object_or_404(MyModel, pk=1)
This example is equivalent to:
from django.http import Http404
def my_view(request):
try:
my_object = MyModel.objects.get(pk=1)
except MyModel.DoesNotExist:
raise Http404("No MyModel matches the given query.")
The most common use case is to pass a Model
, as
shown above. However, you can also pass a
QuerySet
instance:
queryset = Book.objects.filter(title__startswith='M')
get_object_or_404(queryset, pk=1)
The above example is a bit contrived since it’s equivalent to doing:
get_object_or_404(Book, title__startswith='M', pk=1)
but it can be useful if you are passed the queryset
variable from somewhere
else.
Finally, you can also use a Manager
. This is useful
for example if you have a
custom manager:
get_object_or_404(Book.dahl_objects, title='Matilda')
You can also use
related managers
:
author = Author.objects.get(name='Roald Dahl')
get_object_or_404(author.book_set, title='Matilda')
Note: As with get()
, a
MultipleObjectsReturned
exception
will be raised if more than one object is found.
get_list_or_404
¶get_list_or_404
(klass, *args, **kwargs)[source]¶Returns the result of filter()
on a
given model manager cast to a list, raising Http404
if
the resulting list is empty.
The following example gets all published objects from MyModel
:
from django.shortcuts import get_list_or_404
def my_view(request):
my_objects = get_list_or_404(MyModel, published=True)
This example is equivalent to:
from django.http import Http404
def my_view(request):
my_objects = list(MyModel.objects.filter(published=True))
if not my_objects:
raise Http404("No MyModel matches the given query.")
Mar 06, 2018