O Djanfo fornece muitos “decorators” que podem ser aplicados em “views” para suportar várias características HTTP.
See Decorating the class for how to use these decorators with class-based views.
Os “decorators” em django.views.decorators.http podem ser usados para restringir acesso a “views” baseado no método de requisição . Estes “decorators” retornarão uma django.http.HttpResponseNotAllowed se a condição não for atendida.
require_http_methods(request_method_list)¶“Decorator” que requer que uma “view” aceite somente alguns métodos de requisição em particular. Uso:
from django.views.decorators.http import require_http_methods
@require_http_methods(["GET", "POST"])
def my_view(request):
# I can assume now that only GET or POST requests make it this far
# ...
pass
Note que o método de requisição deve estar em maiúsculas.
Support for wrapping asynchronous view functions was added.
require_GET()¶“Decorator” que requer que a “view” somente aceite o método GET.
Support for wrapping asynchronous view functions was added.
require_POST()¶“Decorator” que requer que a “view” somente aceite o método POST.
Support for wrapping asynchronous view functions was added.
require_safe()¶“Decorator” que requer que a “view” somente aceite os métodos GET e HEAD. Estes métodos são geralmente considerados “seguros” porque eles não tem a importância de tomar uma ação além de retornar o conteúdo requisitado.
Nota
Web servers should automatically strip the content of responses to HEAD
requests while leaving the headers unchanged, so you may handle HEAD
requests exactly like GET requests in your views. Since some software,
such as link checkers, rely on HEAD requests, you might prefer
using require_safe instead of require_GET.
Support for wrapping asynchronous view functions was added.
Os seguintes “decorators” em django.views.decorators.http podem ser usados para controlar o comprtamento do “cache” em algumas “views” em particular.
condition(etag_func=None, last_modified_func=None)¶etag(etag_func)¶last_modified(last_modified_func)¶Estes “decorators” podem ser usados para gerar ETag e cabeçalhos Last-Modified; veja processamento condicional de “view”.
Support for wrapping asynchronous view functions was added.
Os “decorators” em django.views.decorators.gzip controlam a compressão de conteúdo baseados em cada “view”.
gzip_page()¶O “decorator” comprime o conteúdo se o navegador permitir compressão “gzip”. Ele define o cabeçalho Vary de acordo, então aquel cache irá basea seu armazenamento no cabeçalho Accept-Encoding.
Support for wrapping asynchronous view functions was added.
Os “decorators” em django.views.decorators.vary podem ser usados para controlar o “cacheamento” baseado em cabeçalhos específicos de requisições.
vary_on_cookie(func)¶Support for wrapping asynchronous view functions was added.
vary_on_headers(*headers)¶O cabeçalho Vary define quais cabeçalhos de requisições um mecânismo de “cache” deve levar em consideração ao construir sua chave de “cache”.
Veja usando cabeçalhos “vary”.
Support for wrapping asynchronous view functions was added.
Os “decorators” em django.views.decorators.cache controlam o “cacheamento” do lado do servidor e do cliente.
cache_control(**kwargs)¶This decorator patches the response’s Cache-Control header by adding
all of the keyword arguments to it. See
patch_cache_control() for the details of the
transformation.
Support for wrapping asynchronous view functions was added.
never_cache(view_func)¶This decorator adds an Expires header to the current date/time.
This decorator adds a Cache-Control: max-age=0, no-cache, no-store,
must-revalidate, private header to a response to indicate that a page
should never be cached.
Each header is only added if it isn’t already set.
Support for wrapping asynchronous view functions was added.
The decorators in django.views.decorators.common allow per-view
customization of CommonMiddleware behavior.
no_append_slash()¶This decorator allows individual views to be excluded from
APPEND_SLASH URL normalization.
Support for wrapping asynchronous view functions was added.
ago. 06, 2024