Denna handledning börjar där Tutorial 3 slutade. Vi fortsätter med web-poll applikationen och kommer att fokusera på formulärbehandling och att minska vår kod.
\n\nLåt oss uppdatera vår mall för detaljer om omröstningen (”polls/detail.html”) från den senaste handledningen, så att mallen innehåller ett HTML-element <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>\nEn snabb genomgång:
\nOvanstående mall visar en alternativknapp för varje frågealternativ. Varje alternativknapps värde är det associerade frågevalets ID. Namnet på varje alternativknapp är ”val”. Det betyder att när någon väljer en av alternativknapparna och skickar in formuläret, skickar den POST-data choice=# där # är ID för det valda valet. Detta är det grundläggande konceptet för HTML-formulär.
Vi ställer in formulärets action till {% url 'polls:vote' question.id %}, och vi ställer in method="post". Att använda method="post" (i motsats till method="get") är mycket viktigt, eftersom handlingen att skicka in detta formulär kommer att ändra data på serversidan. När du skapar ett formulär som ändrar data på serversidan, använd method="post". Detta tips är inte specifikt för Django; det är bra webbutvecklingspraxis i allmänhet.
forloop.counter anger hur många gånger for-taggen har gått igenom sin loop
Eftersom vi skapar ett POST-formulär (som kan ha effekten av att ändra data) måste vi oroa oss för Cross Site Request Forgeries. Tack och lov behöver du inte oroa dig för hårt, eftersom Django kommer med ett användbart system för att skydda mot det. Kort sagt, alla POST-formulär som är inriktade på interna webbadresser bör använda {% csrf_token %} malltagg.
Låt oss nu skapa en Django-vy som hanterar de inskickade uppgifterna och gör något med dem. Kom ihåg att vi i Tutorial 3 skapade en URLconf för polls-programmet som innehåller den här raden:
\npolls/urls.pypath("<int:question_id>/vote/", views.vote, name="vote"),\nVi skapade också en dummyimplementering av funktionen vote(). Låt oss skapa en riktig version. Lägg till följande i polls/views.py:
polls/views.pyfrom django.db.models import F\nfrom 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 = F("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,)))\nDen här koden innehåller några saker som vi ännu inte har gått igenom i den här handledningen:
\nrequest.POST är ett ordboksliknande objekt som låter dig komma åt inskickade data med nyckelnamn. I det här fallet returnerar request.POST['choice'] ID:t för det valda valet som en sträng. request.POST-värden är alltid strängar.
Observera att Django också tillhandahåller request.GET för åtkomst till GET-data på samma sätt - men vi använder uttryckligen request.POST i vår kod för att säkerställa att data endast ändras via ett POST-anrop.
request.POST['choice'] kommer att ge upphov till KeyError om choice inte angavs i POST-data. Ovanstående kod kontrollerar för KeyError och visar frågeformuläret på nytt med ett felmeddelande om choice inte har angetts.
F("votes") + 1 instruerar databasen att öka antalet röster med 1.
Efter att ha ökat antalet val returnerar koden en HttpResponseRedirect snarare än en vanlig HttpResponse. HttpResponseRedirect tar ett enda argument: URL:en till vilken användaren kommer att omdirigeras (se följande punkt för hur vi konstruerar URL:en i det här fallet).
Som Python-kommentaren ovan påpekar bör du alltid returnera en HttpResponseRedirect efter framgångsrik hantering av POST-data. Det här tipset är inte specifikt för Django; det är god praxis för webbutveckling i allmänhet.
Vi använder funktionen reverse() i konstruktören HttpResponseRedirect i det här exemplet. Denna funktion hjälper till att undvika att behöva hårdkoda en URL i vyfunktionen. Den får namnet på den vy som vi vill skicka kontroll till och den variabla delen av URL-mönstret som pekar på den vyn. I det här fallet, med hjälp av URLconf som vi ställde in i Tutorial 3, kommer detta reverse()-anrop att returnera en sträng som
"/polls/3/results/"\ndär 3 är värdet av question.id. Denna omdirigerade URL kommer sedan att anropa vyn 'results för att visa den slutliga sidan.
Som nämnts i Tutorial 3 är request ett HttpRequest-objekt. För mer information om HttpRequest-objekt, se dokumentation om begäran och svar.
När någon har röstat på en fråga omdirigeras vyn vote() till resultatsidan för frågan. Låt oss skriva den vyn:
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})\nDetta är nästan exakt samma sak som vyn detail() från Tutorial 3. Den enda skillnaden är mallnamnet. Vi kommer att åtgärda denna redundans senare.
Skapa nu mallen 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>\nGå nu till /polls/1/ i din webbläsare och rösta på frågan. Du bör se en resultatsida som uppdateras varje gång du röstar. Om du skickar in formuläret utan att ha gjort något val bör du se ett felmeddelande.
Vyerna detail() (från Tutorial 3) och results() är mycket korta - och, som nämnts ovan, överflödiga. Vyn index(), som visar en lista med omröstningar, är liknande.
Dessa vyer representerar ett vanligt fall av grundläggande webbutveckling: hämta data från databasen enligt en parameter som skickas i webbadressen, ladda en mall och returnera den renderade mallen. Eftersom detta är så vanligt tillhandahåller Django en genväg, kallad ”generic views” -systemet.
\nGeneriska vyer abstraherar vanliga mönster till den punkt där du inte ens behöver skriva Python-kod för att skriva en app. Till exempel abstraherar de generiska vyerna ListView och DetailView begreppen ”visa en lista med objekt” respektive ”visa en detaljsida för en viss typ av objekt”.
Låt oss konvertera vår poll-app till att använda det generiska vy-systemet, så att vi kan ta bort en hel del av vår egen kod. Vi måste ta några steg för att göra konverteringen. Vi kommer att göra det:
\nKonvertera URLconf.
Ta bort några av de gamla, onödiga vyerna.
Introducera nya vyer baserade på Djangos generiska vyer.
Läs vidare för mer information.
\n\nFörst öppnar du URLconf i polls/urls.py och ändrar den så här:
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]\nObservera att namnet på det matchade mönstret i söksträngarna för det andra och tredje mönstret har ändrats från <question_id> till <pk>. Detta är nödvändigt eftersom vi kommer att använda den generiska vyn DetailView för att ersätta våra vyer detail() och results(), och den förväntar sig att det primära nyckelvärdet som fångas från URL:en ska heta "pk".
Därefter ska vi ta bort våra gamla vyer index, detail och results och använda Djangos generiska vyer istället. För att göra det, öppna filen polls/views.py och ändra den så här:
polls/views.pyfrom django.db.models import F\nfrom 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.\n ...\nVarje generisk vy måste veta vilken modell den ska agera utifrån. Detta tillhandahålls antingen med attributet model (i detta exempel model = Question för DetailView och ResultsView) eller genom att definiera metoden get_queryset() (som visas i IndexView).
Som standard använder den generiska vyn DetailView en mall som heter <app name>/<model name>_detail.html. I vårt fall skulle den använda mallen "polls/question_detail.html". Attributet template_name används för att tala om för Django att använda ett specifikt mallnamn istället för det autogenererade standardmallnamnet. Vi anger också template_name för listvyn results - detta säkerställer att resultatvyn och detaljvyn har ett annat utseende när de renderas, även om de båda är en DetailView bakom kulisserna.
På samma sätt använder den generiska vyn ListView en standardmall som heter <app name>/<model name>_list.html; vi använder template_name för att tala om för ListView att använda vår befintliga mall "polls/index.html".
I tidigare delar av handledningen har mallarna försetts med en kontext som innehåller kontextvariablerna question och latest_question_list. För DetailView tillhandahålls question-variabeln automatiskt - eftersom vi använder en Django-modell (Question) kan Django bestämma ett lämpligt namn för kontextvariabeln. För ListView är dock den automatiskt genererade kontextvariabeln question_list. För att åsidosätta detta tillhandahåller vi attributet context_object_name, som anger att vi vill använda latest_question_list istället. Som ett alternativt tillvägagångssätt kan du ändra dina mallar för att matcha de nya standardkontextvariablerna - men det är mycket lättare att berätta för Django att använda den variabel du vill ha.
Kör servern och använd din nya polling-app baserad på generiska vyer.
\nFör fullständig information om generiska vyer, se dokumentation om generiska vyer.
\nNär du känner dig bekväm med formulär och generiska vyer kan du läsa del 5 av denna handledning för att lära dig hur du testar vår polls app.
\n