Ten tutorial zaczyna się, gdzie skończył się Tutorial 3 </intro/tutorial03>. Kontynuujemy prace nad aplikacją web-ankiet i skupimy się na przetwarzaniu formularza i przycinaniu naszego kodu.
\n\nZaktualizujmy nasz szablon szczegółów ankiety („polls/detail.html”) z ostatniego tutoriala, aby zawierał element 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>\nKrótkie sprawozdanie:
\nPowyższy szablon wyświetla przycisk opcji dla każdej z odpowiedzi. Atrybut value każdego przycisku opcji to ID związanej z pytaniem odpowiedzi. Atrybut name każdego przycisku opcji to "choice". To znaczy, że kiedy ktoś wybierze jeden z przycisków opcji i wyśle formularz, formularz wyśle dane POST choice=#, gdzie # jest ID wybranej odpowiedzi. To jest podstawowa idea formularzy HTML.
Ustawiamy atrybut action formularza na {% url 'polls:vote' question.id %} i ustawiamy method="post". Użycie method="post" (w opozycji do method="get") jest bardzo ważne, ponieważ akt wysłania formularza zmieni dane po stronie serwera. Kiedykolwiek tworzysz formularz, który zmienia dane po stronie serwera, używaj method="post". Ta wskazówka nie dotyczy tylko Django; jest dobrą praktyką w web-dewelopmencie.`
forloop.counter mówi ile razy tag for przeszedł przez swoją pętlę
Jako że stworzymy formularz POST (który może mieć efekt modyfikacji danych), musimy martwić się o cross-site request forgeries. Na szczęście, nie musisz przejmować się za bardzo, bo Django oferuje pomocny system przed nimi chroniący. W skrócie: wszystkie formularze POST, które są skierowane na wewnętrzne URL-e powinny używać szablonowego taga {% csrf_token %}.
Teraz stwórzmy widok Django, który obsługuje wysłane dane i coś z nimi robi. Pamiętaj, w Tutorialu 3, stworzyliśmy URLconfa dla aplikacji ankietowej, który zawiera tę linię:
\npolls/urls.pypath("<int:question_id>/vote/", views.vote, name="vote"),\nStworzyliśmy także zaślepkową implementację funkcji vote(). Stwórzmy prawdziwą wersję. Dodaj następujący kod do 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\n\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(\n request,\n "polls/detail.html",\n {\n "question": question,\n "error_message": "You didn't select a choice.",\n },\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,)))\nTen kod zawiera kilka rzeczy, których jeszcze nie omówiliśmy w tym tutorialu:
\nrequest.POST to słownikowy obiekt, który daje dostęp do wysłanych danych według nazwy klucza. W tym przypadku request.POST['choice'] zwraca ID wybranej odpowiedzi jako stringa. Wartości request.POST są zawsze stringami.
Zwróć uwagę, że Django ma także request.GET dające dostęp do danych GET w ten sam sposób – ale my specjalnie używamy request.POST w naszym kodzie, aby upewnić się, że dane są zmieniane tylko przez wywołanie POST.
request.POST['choice'] zgłosi KeyError jeśli atrybutu choice nie było wśród danych POST. Powyższy kod sprawdza KeyError i ponownie wyświetla formularz pytania z komunikatem błędu, jeśli choice nie został wskazany.
Po zwiększeniu licznika odpowiedzi, kod zwraca HttpResponseRedirect zamiast normalnej HttpResponse. HttpResponseRedirect bierze jeden argument: URL, do którego użytkownik będzie przekierowany (zobacz następny punkt, aby dowiedzieć się, jak w tym przypadku kontruujemy URL-e).
Tak jak wskazuje komentarz powyżej w Pythonie, powinieneś zawsze zwracać HttpResponseRedirect po poradzeniu sobie z danymi POST. Ta wskazówka nie jest szczególna dla Django; to ogólnie dobra praktyka w web-dewelopmencie.
Używamy funkcji reverse() w konstruktorze HttpResponseRedirect w tym przykładzie. Ta funkcja pomaga uniknąć konieczności hardkodowania URL-i w funkcji widoku. Daje jej się nazwę widoku, któremu chcemy przekazać kontrolę i zestaw zmiennych z wzorca URL-a, który prowadzi do tego widoku. W tym przypadku, używając URLconfa, którego napisaliśmy w Tutorialu 3, to wywołanie reverse() zwróci taki ciąg znaków:
"/polls/3/results/"\ngdzie 3 jest wartością question.id. Ten przekierowany URL później wywoła widok 'results', aby wyświetlić ostateczną stronę.
Jak wspomniano w Tutorialu 3, request jest obiektem HttpRequest. Po więcej informacji na temat obiektów HttpRequest, zobacz dokumentację żądań i odpowiedzi.
Po tym, jak ktoś zagłosuje w danym pytaniu, widok vote() przekieruje go na stronę wyników dla pytania. Napiszmy ten widok:
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})\nJest prawie identyczny z widokiem detail() z Tutoriala 3. Jedyna różnica to nazwa szablonu. Naprawimy tę redundancję później.
Teraz stwórzmy szablon 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>\nTeraz wejdź na /polls/1/ w swojej przeglądarce i zagłosuj w ankiecie. Powinieneś zobaczyć stronę wyników, która aktualizuje się za każdym razem, kiedy oddasz głosz. Jeśli wyślesz formularz bez wybranej odpowiedzi, powinieneś zobaczyć komunikat błędu.
Widoki detail() (z Tutoriala 3) i results() są bardzo krótkie – i, jak wspomnieliśmy wcześniej, redundantne. Widok index(), który wyświetal listę ankiet, jest podobny.
Te widoki reprezentują częsty przypadek w podstawowym web dewelopmencie: pobieranie danych z bazy danych na podstawie parametru podanego w URL, ładownie szablonu i zwracanie wyrenderowanego szablonu. Z powodu, że jest to tak powszechne, Django dostarcza skrót, nazwany systemem „generycznych widoków”.
\nGeneric views abstract common patterns to the point where you don’t even need to\nwrite Python code to write an app. For example, the\nListView and\nDetailView generic views\nabstract the concepts of „display a list of objects” and\n„display a detail page for a particular type of object” respectively.
Przekonwertujmy naszą aplikację ankietową, aby używała systemu widoków generycznych, abyśmy mogli usunąć sporo naszego własnego kodu. Musimy podjąć kilka kroków, aby dokonać konwersji. Będziemy:
\nKonwertować URLconf.
Usuwać stare, niepotrzebne widoki.
Wprowadzać nowe widoki oparte na generycznych widokach Django.
Kontynuuj czytanie, aby dowiedzieć się szczegółów.
\n\nNajpierw otwórz URLconfa w polls/urls.py i zmień go tak:
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 that the name of the matched pattern in the path strings of the second and\nthird patterns has changed from <question_id> to <pk>. This is\nnecessary because we’ll use the\nDetailView generic view to replace our\ndetail() and results() views, and it expects the primary key value\ncaptured from the URL to be called "pk".
Następnie usuniemy nasze stare widoki index, detail i results i użyjemy zamiast nich generycznych widoków Django. Aby to zrobić, otwórz plik polls/views.py i zmień go w ten sposób:
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.\nEach generic view needs to know what model it will be acting upon. This is\nprovided using either the model attribute (in this example, model =\nQuestion for DetailView and ResultsView) or by defining the\nget_queryset() method (as\nshown in IndexView).
Domyślnie widok generyczny DetailView używa szablonu o nazwie <app name>/<model name>_detail.html. W naszym przypadku użyłby szablonu "polls/question_detail.html". Atrybut template_name jest używany, by kazać Django użyć wskazanego szablonu zamiast samo-wygenerowanej domyślnej nazwy szablonu. Wskazujemy również template_name dla widoku listy results – to powoduje, że widok wyników i widok szczegółów mają inny wygląd po wyrenderowaniu, mimo że oba są DetailView pod maską.
Podobnie widok generyczny ListView używa domyślnego szablonu o nazwie <app name>/<model name>_list.html; używamy template_name, aby powiedzieć ListView, by używała naszego istniejącego szablonu "polls/index.html".
W poprzednich częściach tutoriala szablonom dawaliśmy kontekst, który zawierał zmienne kontekstu question i latest_question_list. Dla DetailView zmienna question jest dostarczona automatycznie – ponieważ używamy modelu Django (Question), Django może wyznaczyć odpowiednią nazwę dla zmiennej kontekstowej. Jednak dla ListView automatycznie generowaną zmienną kontekstową jest question_list. Aby to nadpisać nadajemy wartość atrybutowi context_object_name, wskazując, że chcemy użyć zamiast niej latest_question_list. Alternatywnym podejściem byłoby zmienienie szablonów, aby zgadzały się z nowymi domyślnymi zmiennymi kontekstowymi – ale dużo prościej jest powiedzieć Django, aby używało zmiennej, jakiej chcesz.
Uruchom serwer i użyj nowej aplikacji ankietowej opartej na widokach generycznych.
\nPo wszystkie szczegóły widoków generycznych, sprawdź dokumentację widoków generycznych.
\nKiedy już czujesz się dobrze z formularzami i widokami generycznymi, przeczytaj część 5 tego tutoriala, aby nauczyć się testowania naszej ankietowej aplikacji.
\n