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 a actualizar nuestra plantilla de detalles de encuestas («polls/detail.html») a partir del último tutorial, de modo que la plantilla contenga un 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>\nUn resumen rápido:
\nLa plantilla anterior muestra un botón de opción para cada pregunta de selección. El value de cada botón de opción es la ID de la pregunta de selección asociada. El name de cada botón de opción es "choice". Esto significa que cuando alguien selecciona uno de los botones de opción y envía el formulario, enviará los datos POST choice=# donde # es la ID de la opción seleccionada. Este es el concepto básico de los formularios 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 cuántas veces la etiqueta for ha pasado por el bucle
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.
A continuación, vamos a crear una vista Django que maneje los datos enviados y haga algo con ello. Recuerde que en el Tutorial 3, creamos un URLconf para la aplicación encuestas que incluye esta línea:
\npolls/urls.pypath("<int:question_id>/vote/", views.vote, name="vote"),\nTambién creamos una implementación simulada de la función vote(). Vamos a crear una versión real. Agregue lo siguiente a 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,)))\nEste código incluye algunas cosas que no hemos cubierto todavía en este tutorial:
\nrequest.POST es un objeto tipo diccionario que le permite acceder a los datos presentados mediante el nombre clave. En este caso, request.POST['choice'] retorna la ID de la opción seleccionada como una cadena. Los valores request.POST son siempre cadenas.
Tenga en cuenta que Django también proporciona request.GET para acceder a datos GET de la misma manera, pero estamos usando de manera explícita request.POST en nuestro código, para garantizar que los datos sólo se modifiquen a través de una llamada POST.
request.POST['choice'] levantará un excepción KeyError si no se proporcionó choice en los datos POST. El código anterior busca la excepción KeyError y muestra de nuevo el formulario de pregunta con un mensaje de error si no se ha proporcionado choice.
F("votes") + 1 instructs the database to increase the vote count by 1.
Después de incrementar el conteo de la elección, el código retorna una HttpResponseRedirect en lugar de una HttpResponse normal HttpResponseRedirect toma un único argumento: La URL a la que el usuario será redirigido (vea el siguiente aspecto de cómo construimos la URL en este 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 utilizando la función reverse() en el constructor HttpResponseRedirect en este ejemplo. Esta función ayuda a evitar tener que codificar una URL en la función de vista. Se proporciona el nombre de la vista a la que queremos pasar el control y la parte de la variable del patrón de URL que señala esa vista. En este caso, utilizando la URLconf que configuramos en el Tutorial 3, esta llamada reverse() retornará una cadena como
"/polls/3/results/"\ndonde el 3 es el valor de question.id. Esta URL redirigida entonces llamará a la vista 'results' para mostrar la página final.
Como se mencionó en el Tutorial 3, request es un objeto HttpRequest . Para más información sobre los objetos HttpRequest, consulte la documentación de petición y respuesta.
Después de que alguien vota en una pregunta, la vista vote() remite a la página de resultados de la pregunta. Vamos a escribir dicha vista:
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})\nEsto es casi exactamente lo mismo que la vista detail() del Tutorial 3. La única diferencia es el nombre de la plantilla. Solucionaremos esta redundancia más tarde.
Ahora, cree una plantilla 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>\nA continuación, vaya a /polls/1/ en su navegador y vote en la pregunta. Debería ver una página de resultados que se actualiza cada vez que usted vota. Si usted envía el formulario sin haber seleccionado una opción, usted debería ver el mensaje de error.
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.
These views represent a common case of basic web development: getting data from\nthe database according to a parameter passed in the URL, loading a template and\nreturning the rendered template. Because this is so common, Django provides a\nshortcut, called the «generic views» system.
\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.
Let’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:
\nConvertir el URLconf.
Elimina algunas de las vistas viejas e innecesarias.
Introduce nuevas vistas basadas en las vistas genéricas de Django.
Siga leyendo para conocer más detalles.
\n\nPrimero, abra el URLconf polls/urls.py y modifíquelo de la siguiente manera:
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".
A continuación, vamos a eliminar nuestras viejas vistas index, detail y results y en su lugar vamos a usar las vistas genéricas de Django. Para ello, abra el archivo polls/views.py y modifíquelo de la siguiente manera:
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 ...\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).
Por defecto, la vista genérica DetailView utiliza una plantilla llamada <app name>/<model name>_detail.html. En nuestro caso, utilizaría la plantilla "polls/question_detail.html". El atributo template_name se utiliza para indicarle a Django que utilice un nombre de plantilla específico en vez del nombre de plantilla generado de forma automática. También especificamos el atributo template_name para la vista de lista results, esto garantiza que la vista de resultados y la vista detalle tengan un aspecto diferente cuando sean creadas, a pesar de que las dos son una vista genérica DetailView en segundo plano.
Del mismo modo, la vista genérica ListView utiliza una plantilla predeterminada llamada <app name>/<model name>_list.html; utilizamos el atributo template_name para indicarle a ListView que utilice nuestra plantilla "polls/index.html" existente.
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.
Ejecute el servidor y utilice su nueva aplicación encuesta basada en las vistas genéricas.
\nPara más detalles sobre las vistas genéricas, consulte la documentación de las vistas genéricas.
\nCuando esté familiarizado con los formularios y las vistas genéricas, lea la parte 5 de este tutorial para aprender sobre cómo probar nuestra aplicación encuestas.
\n