As três classes seguintes fornecem a maioria das fincionalidades necessárias para criar “views” do Django. Você pode pensar nelas como “views” mães, as quais podem ser usadas elas mesmas ou serem herdadas. Elas talvez não forneçam todas as capacidades requeridas para projetos, para tais casos existem “Mixins” e “views” genéricas baseadas em classes.
Muitas das “views” baseadas em classes embutidas no Django herdam de outras “views” baseadas em classes ou vários “mixins. Por causa dessa cadeia de heranças é muito importante, que a classe ascendente seja documentada sob a seção título do Ancestors (MRO).MRO é um acronismo em inglês para Ordem de Resolução de Método.
View
¶django.views.generic.base.
View
¶The base view class. All other class-based views inherit from this base
class. It isn’t strictly a generic view and thus can also be imported from
django.views
.
Fluxograma de métodos
Examplo views.py:
from django.http import HttpResponse
from django.views import View
class MyView(View):
def get(self, request, *args, **kwargs):
return HttpResponse("Hello, World!")
Exemplo urls.py:
from django.urls import path
from myapp.views import MyView
urlpatterns = [
path("mine/", MyView.as_view(), name="my-view"),
]
Atributos
http_method_names
¶A lista de nomes de métodos HTTP que esta “view” irá aceitar.
Padrão:
["get", "post", "put", "patch", "delete", "head", "options", "trace"]
Métodos
as_view
(**initkwargs)¶Retorna uma “view” “chamável” que recebe um request e retorna uma resposta:
response = MyView.as_view()(request)
A “view” retornada tem os atributos view_class
e view_initkwargs
.
When the view is called during the request/response cycle, the
setup()
method assigns the HttpRequest
to
the view’s request
attribute, and any positional and/or keyword
arguments captured from the URL pattern to the args
and kwargs
attributes, respectively. Then dispatch()
is called.
If a View
subclass defines asynchronous (async def
) method
handlers, as_view()
will mark the returned callable as a coroutine
function. An ImproperlyConfigured
exception will be raised if both
asynchronous (async def
) and synchronous (def
) handlers are
defined on a single view-class.
Compatibility with asynchronous (async def
) method handlers was
added.
setup
(request, *args, **kwargs)¶Performs key view initialization prior to dispatch()
.
If overriding this method, you must call super()
.
dispatch
(request, *args, **kwargs)¶The view
part of the view – the method that accepts a request
argument plus arguments, and returns an HTTP response.
A implementação padrão irá introspectar o método HTTP e tentar delegar para um método que combine com o método HTTP; um GET
será delegado para get()
, um POST``para um ``post()
, e assim por diante.
Por padrão, uma requisição HEAD
será delegada para get()
. Se você precisa manipular requisições HEAD
de uma maneira diferente de um GET
, você pode sobrescrever o método head()
. veja Supporting other HTTP methods para um exemplo.
http_method_not_allowed
(request, *args, **kwargs)¶If the view was called with an HTTP method it doesn’t support, this method is called instead.
A implementação padrão retorna HttpResponseNotAllowed
com uma lista de métodos permitidos in formato de texto simples.
options
(request, *args, **kwargs)¶Handles responding to requests for the OPTIONS HTTP verb. Returns a
response with the Allow
header containing a list of the view’s
allowed HTTP method names.
If the other HTTP methods handlers on the class are asynchronous
(async def
) then the response will be wrapped in a coroutine
function for use with await
.
Compatibility with classes defining asynchronous (async def
)
method handlers was added.
TemplateView
¶django.views.generic.base.
TemplateView
¶Renderiza um dado template, com o contexto contendo parâmetros capturados na URL.
Ancestrais (MRO)
Essa “view” herda métodos e atributos das seguintes “views”:
django.views.generic.base.TemplateResponseMixin
django.views.generic.base.ContextMixin
django.views.generic.base.View
Fluxograma de métodos
Examplo views.py:
from django.views.generic.base import TemplateView
from articles.models import Article
class HomePageView(TemplateView):
template_name = "home.html"
def get_context_data(self, **kwargs):
context = super().get_context_data(**kwargs)
context["latest_articles"] = Article.objects.all()[:5]
return context
Exemplo urls.py:
from django.urls import path
from myapp.views import HomePageView
urlpatterns = [
path("", HomePageView.as_view(), name="home"),
]
Context
ContextMixin
) com os argumentos nomeados capturados do padrão formatado da URL que serve a “view”.extra_context
keyword
argument for as_view()
.RedirectView
¶django.views.generic.base.
RedirectView
¶Redirecionamentos para uma URL específica.
A URL dada deve pode conter formatação de string no estilo de dicionario, o qual será interpolado com os parâmetros capturados na UTL. Porque a interpoalação de palavras-chave sempre são feitas (mesmo que nenhum argumento seja passado), qualquer caracter "%"
na URL deve ser escrita como "%%"
então o Python irá converte-los para um único sinal de porcentagem na saída.
Se a dada URL é None
, o Django irá retornar um HttpResponseGone
(410).
Ancestrais (MRO)
Essa “view” herda métodos e atributos da seguinte “view”:
Fluxograma de métodos
Examplo views.py:
from django.shortcuts import get_object_or_404
from django.views.generic.base import RedirectView
from articles.models import Article
class ArticleCounterRedirectView(RedirectView):
permanent = False
query_string = True
pattern_name = "article-detail"
def get_redirect_url(self, *args, **kwargs):
article = get_object_or_404(Article, pk=kwargs["pk"])
article.update_counter()
return super().get_redirect_url(*args, **kwargs)
Exemplo urls.py:
from django.urls import path
from django.views.generic.base import RedirectView
from article.views import ArticleCounterRedirectView, ArticleDetailView
urlpatterns = [
path(
"counter/<int:pk>/",
ArticleCounterRedirectView.as_view(),
name="article-counter",
),
path("details/<int:pk>/", ArticleDetailView.as_view(), name="article-detail"),
path(
"go-to-django/",
RedirectView.as_view(url="https://www.djangoproject.com/"),
name="go-to-django",
),
]
Atributos
url
¶A URL para a qual será redirecionada, como string. Ou None
para levantar um erro HTTP 410 (“Gone”).
pattern_name
¶O nome do padrão formatado para URL para redirecionar. O reverso será feito usando o mesmo “args” e “kwargs” como foram passados para esta “view”.
permanent
¶Se o redirecionamento deve ser permanente ou não. A única diferença aqui é o código de estatus HTTP retornado. Se True
, então o redirecionamento usará código de estatus 301. Se False
, o redirecionamento usará código de estatus 302. Por padrão, permanent
é False
.
query_string
¶Se passa ou não no GET a “query string” para o novo local. Se True
, então a “query string” é adicionada à URL. Se False
, entao a “query string” é descartada. Por padrão, query_string
é False
.
Métodos
get_redirect_url
(*args, **kwargs)¶Constrói a URL alvo para redirecionamento.
The args
and kwargs
arguments are positional and/or keyword
arguments captured from the URL pattern, respectively.
A implementação padrão usa url
como a string inicial e realiza a expansão dos parâmetros nomeados %
na string usando os grupos nomeados capturados na URL.
Se url
não está definido, get_redirect_url()
tenta fazer o reverse de pattern_name
usando o que foi capturado na URL (ambos os grupos, nomeados e não nomeados são usados).
Se requisitado via query_string
, também será adicionado a “query string” a URL gerada. Subclasses podem implementar qualquer comportamento que quiser, contanto que o método retorne uma string URL de redirecionamento pronta.
dez. 04, 2023