This tutorial begins where Tutorial 3 left off. We’re\ncontinuing the Web-poll application and will focus on form processing and\ncutting down our code.
\n\nVamos atualizar nosso template de detalhamento da enquete (“polls/detail.html”)\ndo último tutorial, para que ele contenha um elemento HTML <form>:
polls/templates/polls/detail.html<form action="{% url 'polls:vote' question.id %}" method="post">\n{% csrf_token %}\n<fieldset>\n <legend><h1>{{ question.question_text }}</h1></legend>\n {% if error_message %}<p><strong>{{ error_message }}</strong></p>{% endif %}\n {% for choice in question.choice_set.all %}\n <input type="radio" name="choice" id="choice{{ forloop.counter }}" value="{{ choice.id }}">\n <label for="choice{{ forloop.counter }}">{{ choice.choice_text }}</label><br>\n {% endfor %}\n</fieldset>\n<input type="submit" value="Vote">\n</form>\nUma rápida explicação:
\nO template acima exibe um botão radio para cada opção da enquete. O value de cada botão radio está associado ao ID da opção. O name de cada botão radio é a escolha "choice". Isso significa que, quando alguém escolhe um dos botões de radio e submete a formulário, ele vai enviar o dado``choice=#`` por POST onde # é o ID da escolha selecionada. Este é o conceito básico sobre formulários HTML.
We set the form’s action to {% url 'polls:vote' question.id %}, and we\nset method="post". Using method="post" (as opposed to\nmethod="get") is very important, because the act of submitting this\nform will alter data server-side. Whenever you create a form that alters\ndata server-side, use method="post". This tip isn’t specific to\nDjango; it’s good Web development practice in general.
forloop.counter indica quantas vezes a tag :ttag`for` passou pelo laço.
Since we’re creating a POST form (which can have the effect of modifying\ndata), we need to worry about Cross Site Request Forgeries.\nThankfully, you don’t have to worry too hard, because Django comes with a\nhelpful system for protecting against it. In short, all POST forms that are\ntargeted at internal URLs should use the {% csrf_token %}\ntemplate tag.
Agora, vamos criar uma view Django que manipula os dados submetidos e faz algo com eles. Lembre-se, no Tutorial 3, criamos uma URLconf para a aplicação de enquete que inclui esta linha:
polls/urls.pypath('<int:question_id>/vote/', views.vote, name='vote'),\nNós tambem criamos uma implementação falsa da função vote(). Vamos criar a versão real. Adicione o seguinte em polls/views.py:
polls/views.pyfrom django.http import HttpResponse, HttpResponseRedirect\nfrom django.shortcuts import get_object_or_404, render\nfrom django.urls import reverse\n\nfrom .models import Choice, Question\n# ...\ndef vote(request, question_id):\n question = get_object_or_404(Question, pk=question_id)\n try:\n selected_choice = question.choice_set.get(pk=request.POST['choice'])\n except (KeyError, Choice.DoesNotExist):\n # Redisplay the question voting form.\n return render(request, 'polls/detail.html', {\n 'question': question,\n 'error_message': "You didn't select a choice.",\n })\n else:\n selected_choice.votes += 1\n selected_choice.save()\n # Always return an HttpResponseRedirect after successfully dealing\n # with POST data. This prevents data from being posted twice if a\n # user hits the Back button.\n return HttpResponseRedirect(reverse('polls:results', args=(question.id,)))\nEste código inclui algumas coisas que ainda não foram cobertas neste tutorial:
\nrequest.POST é um objeto como dicionários que lhe permite acessar os dados submetidos pelos seus nomes chaves. Neste caso, request.POST['choice'] retorna o ID da opção selecionada, como uma string. Os valores de request.POST são sempre strings.
Note que Django também fornece request.GET para acesar dados GET da mesma forma – mas nós estamos usando attr:request.POST <django.http.HttpRequest.POST> explicitamente no nosso código, para garantir que os dados só podem ser alterados por meio de uma chamada POST.
request.POST['choice'] irá levantar a exceção KeyError caso uma choice não seja fornecida via dados POST. O código acima checa por KeyError e re-exibe o formulário da enquete com as mensagens de erro se uma choice não for fornecida.
Após incrementar uma opção, o código retorna um class:~django.http.HttpResponseRedirect em vez de um normal HttpResponse. HttpResponseRedirect` recebe um único argumento: a URL para o qual o usuário será redirecionado (veja o ponto seguinte para saber como construímos a URL, neste caso).
As the Python comment above points out, you should always return an\nHttpResponseRedirect after successfully dealing with\nPOST data. This tip isn’t specific to Django; it’s good Web development\npractice in general.
Estamos usando a função reverse() no construtor da HttpResponseRedirect neste exemplo. Essa função nos ajuda a evitar de colocar a URL dentro da view de maneira literal. A ele é dado então o nome da “view” que queremos que ele passe o controle e a parte variável do padrão de formato da URL que aponta para a “view”. Neste caso, usando o URLconf nós definimos em Tutorial 3, esta chamada de reverse() irá retornar uma string como
'/polls/3/results/'\nonde o 3 é o valor para question.id. Esta URL redirecionada irá então chamar a view 'results' para exibir a página final.
Como mencionado no Tutorial 3, request é um objeto HttpRequest object. Para mais informações sobre objetos HttpRequest, veja request and response documentation.
Depois que alguém votar em uma enquete, a view vote() redireciona para a página de resultados da enquete. Vamos escrever essa view:
polls/views.pyfrom django.shortcuts import get_object_or_404, render\n\n\ndef results(request, question_id):\n question = get_object_or_404(Question, pk=question_id)\n return render(request, 'polls/results.html', {'question': question})\nIsto é quase exatamente o mesmo que a view detail() do Tutorial 3. A única diferença é o nome do template. Iremos corrigir esta redundância depois.
Agora, crie o template polls/results.html:
polls/templates/polls/results.html<h1>{{ question.question_text }}</h1>\n\n<ul>\n{% for choice in question.choice_set.all %}\n <li>{{ choice.choice_text }} -- {{ choice.votes }} vote{{ choice.votes|pluralize }}</li>\n{% endfor %}\n</ul>\n\n<a href="{% url 'polls:detail' question.id %}">Vote again?</a>\nAgora, vá para /polls/1/ no seu navegador e vote em uma enquete. Você deverá ver uma página de resultados que será atualizado cada vez que você votar. Se você enviar o formulário sem ter escolhido uma opção, você deverá ver a mensagem de erro.
The detail() (from Tutorial 3) and results()\nviews are very short – and, as mentioned above, redundant. The index()\nview, which displays a list of polls, is similar.
Estas views representam um caso comum do desenvolvimento Web básico: obter dados do banco de dados de acordo com um parâmetro passado na URL, carregar um\ntemplate e devolvê-lo renderizado. Por isto ser muito comum, o Django fornece um atalho, chamado sistema de “views genéricas”.
\nViews genéricas abstraem padrões comuns para um ponto onde você nem precisa\nescrever código Python para escrever uma aplicação.
\nLet’s convert our poll app to use the generic views system, so we can delete a\nbunch of our own code. We’ll have to take a few steps to make the conversion.\nWe will:
\nConverta o URLconf.
Delete algumas das views antigas, desnecessárias.
Introduz novas views baseadas em views genéricas Django’s.
Leia para obter mais detalhes.
\n\nEm primeiro lugar, abra a URLconf polls/urls.py e modifique para ficar assim:
polls/urls.pyfrom django.urls import path\n\nfrom . import views\n\napp_name = 'polls'\nurlpatterns = [\n path('', views.IndexView.as_view(), name='index'),\n path('<int:pk>/', views.DetailView.as_view(), name='detail'),\n path('<int:pk>/results/', views.ResultsView.as_view(), name='results'),\n path('<int:question_id>/vote/', views.vote, name='vote'),\n]\nNote que o nome da descrição encontrada nas strings de caminhos da segundo e da terceira descrição foi alterado de <question_id> para <pk>.
Em seguida, vamos remover a nossas velhas views index, `` detail``, e results e usar views genéricas do Django em seu lugar. Para fazer isso, abra o arquivo polls/views.py e alterar para:
polls/views.pyfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import get_object_or_404, render\nfrom django.urls import reverse\nfrom django.views import generic\n\nfrom .models import Choice, Question\n\n\nclass IndexView(generic.ListView):\n template_name = 'polls/index.html'\n context_object_name = 'latest_question_list'\n\n def get_queryset(self):\n """Return the last five published questions."""\n return Question.objects.order_by('-pub_date')[:5]\n\n\nclass DetailView(generic.DetailView):\n model = Question\n template_name = 'polls/detail.html'\n\n\nclass ResultsView(generic.DetailView):\n model = Question\n template_name = 'polls/results.html'\n\n\ndef vote(request, question_id):\n ... # same as above, no changes needed.\nNós estamos usando duas views genéricas aqui: ListView e DetailView. Respectivamente, essas duas views abstraem o conceito de exibir uma lista de objetos e exibir uma página de detalhe para um tipo particular de objeto.
Cada “view” genérica precisa saber qual é o modelo que ela vai agir. Isto é fornecido usando o atributo model.
A view genérica DetailView espera o valor de chave primaria capturado da URL chamada "pk", então mudamos question_id para pk para as views genérica.
Por padrão, a “view” genérica DetailView utiliza um template chamado <app name>/<model name>_detail.html`. Em nosso caso, ela vai utilizar o template `"polls/question_detail.html". O atributo template_name é usado para indicar ao Django para usar um nome de template em vez de auto gerar uma nome de template. Nós também especificamos template_name para a view de listagem de results – isto garante que a view de detalhe tem uma aparência quando renderizada, mesmo que sejam tanto um class:~django.views.generic.detail.DetailView por trás das cenas.
Semelhantemente, a view genérica ListView utiliza um template chamado <app name>/<model name>_list.html; usamos template_name para informar ListView para usar nossos templates "polls/index.html".
Nas partes anteriores deste tutorial, os templates tem sido fornecidos com um contexto que contém as variáveis question e latest_question_list. Para a DetailView a variavel question é fornecida automaticamente – já que estamos usando um modelo Django (Question), Django é capaz de determinar um nome apropriado para a variável de contexto. Contudo, para ListView, a variável de contexto gerada automaticamente é question_list. Para sobrescrever nós fornecemos o atributo context_object_name, especificando que queremos usar latest_question_list no lugar. Como uma abordagem alternativa, você poderia mudar seus templates para casar o novo padrão das variáveis de contexto – mas é muito fácil dizer para o Django usar a variável que você quer.
Execute o servidor, e use sua nova aplicação de enquete baseada em generic views.
\nPara detalhes completos sobre views genéricas, veja a documentação de generic views documentation.
\nQuando você estiver confortável com formulários e generic views, leia a parte 5 deste tutorial para aprender sobre como testar nossa aplicação de enquete.
\n