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.
Django does not provide a shortcut function which returns a
TemplateResponse because the constructor
of TemplateResponse offers the same level
of convenience as render().
requesttemplate_namecontextA 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_instanceThe 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_typeDEFAULT_CONTENT_TYPE setting.status200.current_appA 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.
usingNAME of a template engine to use for
loading the template.The using 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]¶This function preceded the introduction of render() and works
similarly except that it doesn’t make the request available in the
response. It’s not recommended and is likely to be deprecated in the future.
template_namecontextA 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_instanceThe 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_typeDEFAULT_CONTENT_TYPE setting.status200.usingNAME of a template engine to use for
loading the template.The status and using parameters were added.
Deprecated since version 1.8: The dirs parameter was deprecated.
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.
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('https://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.")
May 02, 2016