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\nΑς αναβαθμίσουμε το HTML template («polls/detail.html»), από τον προηγούμενο οδηγό, στο οποίο εμφανίζουμε τις λεπτομέρειες της ψηφοφορίας. Αυτή τη φορά θα προσθέσουμε ένα HTML <form> element:
<h1>{{ question.question_text }}</h1>\n\n{% if error_message %}<p><strong>{{ error_message }}</strong></p>{% endif %}\n\n<form action="{% url 'polls:vote' question.id %}" method="post">\n{% csrf_token %}\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<input type="submit" value="Vote">\n</form>\nΕδώ συμβαίνουν τα εξής:
\nΤο παραπάνω template εμφανίζει ένα radio button για κάθε επιλογή ερώτησης. Η τιμή (value) κάθε radio button είναι το ID αυτού. Το όνομα (name) σε όλα τα radio buttons είναι "choice". Αυτό σημαίνει ότι, όταν κάποιος επιλέγει κάποια από τις πιθανές απαντήσεις και κάνει submit τη φόρμα, τότε θα σταλούν (στον server) τα εξής δεδομένα με τη μέθοδο POST (POST data): choice=# όπου # είναι το ID της επιλεγμένης απάντησης (στέλνεται, δηλαδή, το name του input μαζί με το value του ίδιου σε μια μορφή key=value). Αυτό είναι το βασικό concept των HTML forms.
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 δείχνει τον αριθμό που ο βρόγχος επανάληψης for έχει τρέξει. Αυτό το κάνουμε για να λάβει κάθε input element μοναδικό id.
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.
Ας δημιουργήσουμε τώρα ένα Django view το οποίο θα χειριστεί τα δεδομένα τα οποία έγιναν submit από τη φόρμα. Θυμηθείτε ότι στον Οδηγό 3, δημιουργήσαμε ένα URLconf, το οποίο περιλαμβάνει τη γραμμή:
\npath('<int:question_id>/vote/', views.vote, name='vote'),\nΔημιουργήσαμε επίσης μια πρόχειρη υλοποίηση της συνάρτησης (view) vote(). Ας αναβαθμίσουμε και αυτό το view για να χειριστεί τα data. Προσθέστε τα ακόλουθα στο αρχείο polls/views.py:
from 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,)))\nΟ παραπάνω κώδικας περιλαμβάνει μερικά πράγματα τα οποία δεν έχουμε καλύψει μέχρι τώρα στον οδηγό:
\nΤο object request.POST έχει τη μορφή ενός dictionary το οποίο σας επιτρέπει να έχετε πρόσβαση στα submitted data μέσω του ονόματος του key (όπως ακριβώς λειτουργεί ένα dictionary στην Python). Στην περίπτωση μας, το request.POST['choice'] επιστρέφει το ID της επιλεγμένης απάντησης, υπό τη μορφή ενός string. Όλες οι τιμές μέσα το object request.POST έχουν τη μορφή string.
Σημειώστε ότι το Django παρέχει επίσης ανάλογη πρόσβαση στα GET data (αν χρησιμοποιηθεί το method="get") μέσω του object request.GET – αλλά στο συγκεκριμένο παράδειγμα χρησιμοποιούμε αποκλειστικά την request.POST, για να σιγουρευτούμε ότι τα data θα αλλάξουν (στη βάση δεδομένων) μόνο από κάποιο POST call (και ότι τυχόν από κάπου αλλού).
Το object request.POST['choice'] θα κάνει raise το exception KeyError (όπως και ένα κοινό Python dictionary) αν το key choice δεν βρεθεί (δεν υπάρχει, δηλαδή, στα POST data). Ο παραπάνω κώδικας κάνει handle το exception αυτό με το να επανεμφανίσει τη φόρμα ψηφοφορίας με ένα ανάλογο μήνυμα σφάλματος (error message).
Αφού αυξήσουμε το πλήθος των ψήφων (κατά ένα, κάθε φορά), ο κώδικας επιστρέφει ένα object HttpResponseRedirect παρά ένα συνηθισμένο HttpResponse. Το object HttpResponseRedirect αρχικοποιείται (initializes) με ένα όρισμα (argument): το URL στο οποίο θα ανακατευθυνθεί ο χρήστης (δείτε τις ακόλουθες δύο παραγράφους σχετικά με το πως χτίζουμε το URL σε αυτή την περίπτωση).
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.
Χρησιμοποιούμε τη συνάρτηση reverse() στον constructor της κλάσης HttpResponseRedirect. Η συνάρτηση αυτή βοηθά στο να αποφύγουμε να γράφουμε ολόκληρα τα URLs (hardcode) μέσα στη συνάρτηση view (ή οπουδήποτε αλλού σε Python κώδικα). Σαν ορίσματα παίρνει το όνομα του URL (π.χ αυτό που έχουμε ορίσει ως name μέσα στη συνάρτηση url() στο αρχείο polls/urls.py, με πρόθεμα το όνομα του application για τυχόν namespacing) και τυχόν arguments (είτε positional είτε named) τα οποία έχουν περαστεί μέσα στο URL (αυτά που “αιχμαλωτίστηκαν” λόγω των regular expressions). Στη δικιά μας περίπτωση, χρησιμοποιώντας το URLconf που δημιουργήσαμε στον Οδηγό 3, η κλήση της συνάρτησης reverse() θα επιστρέψει ένα string όπως το παρακάτω:
'/polls/3/results/'\nόπου 3 είναι η τιμή του question.id. Αυτό το URL θα καλέσει το view με το όνομα 'results' για να εμφανίσει τη σελίδα (το rendered template, δηλαδή, polls/detail.html). Όταν λέμε rendered template ας εξηγήσουμε τι εννοούμε. Είναι πολύ απλό. Μέσα σε ένα template (συνήθως μια HTML σελίδα), συνήθως βάζουμε περιεχόμενο το οποίο αναμένουμε να “γεμίσει” με μια τιμή από κάπου (συνήθως από το view που κάλεσε αυτό το template). Είδαμε κάτι τέτοιο στον Οδηγό 3 όπου στο template polls/detail.html βάλαμε την έκφραση {{ choice.choice_text }} μέσα σε ένα <li></li> HTML element. Αυτή η τιμή θα “γεμίσει” από το context που θα περάσει το view στο template (μέσω της render() φυσικά). Το context δεν είναι τίποτε άλλο παρά ένα dictionary όπου τα keys ονομάζονται context variables. Υπολογίστηκαν κάποιες τιμές στο view και με κάποιον τρόπο θα πρέπει να περαστούν στο template. Όταν το template γεμίσει με τις απαραίτητες τιμές τότε έχει γίνει rendered.
Όπως αναφέρθηκε στον Οδηγό 3, το request είναι ένα object της κλάσης HttpRequest. Για περισσότερες πληροφορίες σχετικά με τα objects της κλάσης HttpRequest, δείτε το άρθρο εγχειρίδιο του request και response.
Όταν κάποιος ψηφίσει στην ερώτηση, τότε το view vote() θα ανακατευθύνει το χρήστη στη σελίδα των αποτελεσμάτων για αυτή την ερώτηση. Ας γράψουμε αυτό το view:
from 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})\nΑυτό το view είναι σχεδόν πανομοιότυπο με το detail() από τον Οδηγό 3. Η μόνη διαφορά είναι το όνομα του template. Θα φτιάξουμε αυτό τον πλεονασμό αργότερα. Μας αρέσει να ακολουθάμε την τακτική DRY (don’t repeat yourself).
Τώρα, δημιουργήστε το template με το όνομα 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>\nΜεταβείτε στη σελίδα /polls/1/ και ψηφίστε. Κάθε φορά που ψηφίζετε θα βλέπετε τη σελίδα με τα αποτελέσματα της ερώτησης. Αν κάνετε submit τη φόρμα δίχως να επιλέξετε κάποια απάντηση θα δείτε ένα μήνυμα σφάλματος.
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.
Αυτά τα views αναπαριστούν μια κοινή πρακτική γενικά στο Web development: φέρνουν data από την database ανάλογα τις παραμέτρους που εισήχθησαν στο URL, φορτώνουν ένα template και επιστρέφουν ένα rendered template. Επειδή αυτό είναι τόσο κοινότυπο, το Django προσφέρει μια συντόμευση, η οποία ονομάζεται σύστημα «generic views».
\nΤα generic views απλοποιούν αυτές τις τόσο συνηθισμένες τακτικές σε βαθμό που δεν χρειάζεται να γράψετε καθόλου Python κώδικα για να φτιάξετε ένα app.
\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:
\nΜετατροπή των URLconf.
Διαγραφή παλιού κώδικα, αχρησιμοποίητα views.
Εισαγωγή σε νέου είδους views, βασισμένα πάνω στα generic views του Django.
Συνεχίστε να διαβάζετε για λεπτομέρειες.
\n\nΑνοίξτε πρώτα το URLconf αρχείο polls/urls.py και αλλάξτε το σε:
from 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>.
Επόμενο βήμα είναι να αφαιρέσουμε τα παλιά (πλέον) index, detail και results views και να χρησιμοποιήσουμε τα generic views του Django. Για να γίνει αυτό, ανοίξτε το αρχείο polls/views.py και αλλάξτε το σε:
from 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Χρησιμοποιούμε δύο generic views:\nΤο ListView και το DetailView. Αντίστοιχα, αυτά τα δύο views απλοποιούν τα concepts της «προβολής μια λίστας από objects» και της «προβολής μιας σελίδας λεπτομερειών για ένα συγκεκριμένου τύπου object.»
Κάθε generic view χρειάζεται να γνωρίζει το μοντέλο με το οποίο θα συνεργαστεί. Αυτό επιτυγχάνεται με το attribute model.
Το DetailView generic view περιμένει μια τιμή ενός primary key (ID, αν θέλετε) η οποία έχει “αιχμαλωτιστεί” στο URL υπό το όνομα "pk". Αυτός είναι ο λόγος που μετονομάσαμε το question_id σε pk.
Από προεπιλογή, το generic view DetailView χρησιμοποιεί ένα template με το όνομα <appname>/<modelname>_detail.html. Στην περίπτωση μας θα χρησιμοποιήσει το template με το όνομα "polls/question_detail.html". Μπορούμε να παρακάμψουμε (override) αυτή τη συμπεριφορά, θέτοντας την τιμή του attribute template_name σε μια δική μας. Ορίζουμε, επίσης, ένα δικό μας template_name και για το view results – αυτό εξασφαλίζει ότι το results view και το detail view θα έχουν διαφορετική εμφάνιση όταν γίνουν rendered, παρά το γεγονός ότι και τα δύο είναι τύπου DetailView.
Ομοίως, το generic view ListView χρησιμοποιεί, εξ ορισμού, ένα template με το όνομα <appname>/<modelname>_list.html. Παρακάμπτουμε, και εδώ, τη συμπεριφορά αυτή θέτοντας τη τιμή του attribute template_name στο string "polls/index.html", το οποίο έχουμε ήδη υλοποιήσει.
In previous parts of the tutorial, the templates have been provided\nwith a context that contains the question and latest_question_list\ncontext variables. For DetailView the question variable is provided\nautomatically – since we’re using a Django model (Question), Django\nis able to determine an appropriate name for the context variable.\nHowever, for ListView, the automatically generated context variable is\nquestion_list. To override this we provide the context_object_name\nattribute, specifying that we want to use latest_question_list instead.\nAs an alternative approach, you could change your templates to match\nthe new default context variables – but it’s a lot easier to tell Django to\nuse the variable you want.
Τρέξτε τον server και παίξτε με τη νέα σας εφαρμογή που είναι βασισμένη στα generic views.
\nΓια όλες τις λεπτομέρειες πάνω στα generic views, δείτε το άρθρο εγχειρίδιο (documentation) των generic views.
\nΌταν είστε εξοικειωμένοι με τις φόρμες και τα generic views διαβάστε το πέμπτο μέρος αυτού του οδηγού για να μάθετε πως να κάνετε τεστ (test) στην εφαρμογή σας.
\n