polls/views.py 
 def detail(request, question_id): 
     return HttpResponse("Estas mirando la pregunta %s." % question_id) 
  
 def results(request, question_id): 
     response = "Los resultados para la pregunta %s son:" 
     return HttpResponse(response % question_id) 
  
 def vote(request, question_id): 
     return HttpResponse("Estas votando en la pregunta %s." % question_id)

Después de crear estas nuevas vistas tenemos que dirigirnos al módulo “polls.urls” para asignarles una URL:

polls/urls.py 
 from django.conf.urls import url 
 from . import views 
  
 urlpatterns = [ 
     # ex: /polls/ 
     url(r'^$', views.index, name='index'), 
     # ex: /polls/5/ 
     url(r'^(?P<question_id>[0-9]+)/$', views.detail, name='detail'), 
     # ex: /polls/5/results/ 
     url(r'^(?P<question_id>[0-9]+)/results/$', views.results, name='results'), 
     # ex: /polls/5/vote/ 
     url(r'^(?P<question_id>[0-9]+)/vote/$', views.vote, name='vote'), 
 ]

Si nos dirigimos a nuestro navegador e introducimos la siguiente dirección: “/polls/34/”. La función que se ejecutará será la “detail()” y nos mostrará el ID que pasamos en la URL. Probemos también “/polls/34/results/” y “/polls/34/vote/”, estas dos páginas nos mostrarán la página de resultados y la página de votación respectivamente.

Cuando alguien solicite una página a nuestro sitio web, por ejemplo “/polls/34/”, Django se dirigirá al módulo “mysite.urls” que se encuentra definido en la opción “ROOT_URLCONF”. Una vez ahí, buscará la variable “urlpatterns” y recorrerá las expresiones regulares en orden. Las llamadas “include()” que puedan estar definidas sólo hacen referencia a otras “configuraciones de URL”. Fijaros que las expresiones regulares para los “include()” no tienen un “$” sino que terminan en una barra, esto es debido a que el carácter “$” indica el fin de un “string” en un patrón. Cada vez que Django encuentra un “include()”, recorta la parte de la URL que coincide hasta ese punto y envía el string restante al “configurador de URL” correspondiente continuar con el proceso.

La idea de utilizar “include()” es la de hacer fácil tener “URLs” propias para cada aplicación. Como nuestra aplicación “polls” tiene su propio “configurador de URL” (polls/urls.py), las “URLs” de la app se pueden poner bajo “/polls/”, o bajo “/fun_polls/”, o bajo “/content/polls/”, o cualquier otra ruta que queramos, y la aplicación seguirá funcionando.

Una vez explicado esto veamos que ocurre si un usuario se dirige a “/polls/34/” en nuestra aplicación:

“Django” encontrará coincidencia en ‘^polls/’

Entonces, “Django” va a recortar el texto que coincide (“polls/”) y enviará el texto restante que sería: “34/” al “configurador de URL” de la aplicación que sería “polls.urls” para seguir el proceso, donde coincidirá con con el patrón “r’^(?P<question_id>[0-9]+)/$’”, dando como resultado una llamada a la vista detail() de la forma:

detail(request=<HttpRequest object>, question_id='34')

Os estaréis preguntando cómo es posible que “Django” sepa que tiene que poner el valor “34” en el parámetro “question_id”, esto es por la expresión regular que hemos utilizado como patrón: “ (?P<question_id>[0-9]+) ”. Como hemos colocado paréntesis alrededor de este patrón el “framework” lo que hace es “captura” el texto que coincida con el patrón y ese valor se pasas como argumento a la función de la vista; ?P<question_id> define el nombre que se usará para identificar la coincidencia; y [0-9]+ es una expresión regular para buscar una secuencia de dígitos (i.e., un número).

Como los patrones de URL son expresiones regulares, no hay realmente un límite de lo que se puede hacer con ellos.

Creando vistas con funcionalidad

Cada vista es responsable de realizar dos acciones:

• Devolver un objeto HttpResponse con el contenido de la página solicitada.
• Lanzar una excepción, por ejemplo Http404, cuando se produce un error.

Una vista puede leer registros de una base de datos, o puede usar un sistema de plantillas como el de “Django”, o puede generar un archivo PDF, una salida XML, crear un archivo ZIP, o realizar cualquier funcionalidad que no pueda imaginar. Todo lo que “Django” espera es un “HttpResponse” o una excepción.

A continuación, os vamos a mostrar cómo podría ser la vista “index()” mostrando las 5 preguntas más recientes en el sistema, separadas por comas, de acuerdo a la fecha de publicación:

polls/views.py 
 from django.http import HttpResponse 
 from .models import Pregunta 
  
 def index(request): 
    lista_ultimas_preguntas = Pregunta.objects.order_by('-fecha_publi')[:5] 
    salida= ', '.join([p.texto_pregunta for p in lista_ultimas_preguntas]) 
    return HttpResponse(salida) 
 # Leave the rest of the views (detail, results, vote) unchanged

Al crear toda la página dentro de la vista, si en un futuro quisiéramos cambiar el aspecto de la página tendríamos que editar el código que hemos escrito. Por este motivo vamos a utilizar el sistema de plantillas que nos proporciona Django, de modo que separemos el diseño de la página de la funcionalidad que hemos escrito en Python. Para ello tendremos que crear una plantilla que pueda utilizar nuestra vista.

Lo primero que tendremos que hacer para crear esta plantilla es crear un directorio llamado “templates” en nuestro directorio “polls”. Ya que es donde “Django” se va a dirigir para buscar las plantillas. En la parte VII de este tutorial ya os explicamos cómo había que configurar las opciones para que “Django” supiera encontrar las plantillas de nuestra aplicación. Os recomendamos que os volváis a dirigir a esta parte del tutorial para aseguraros de que tenéis bien configurado el fichero “mysite/settings.py”.

Organizando los templates

Si quisiéramos, podríamos tener todas nuestras plantillas juntas en un gran directorio “templates” y la aplicación funcionaría perfectamente. Sin embargo, esta plantilla pertenece a la aplicación “polls” por lo tanto, a diferencia de la plantilla del administrador que creamos en los capítulos anteriores, vamos a poner esta plantilla en el directorio de plantillas de la aplicación “polls”(polls/templates).

En el directorio “templates” que acabamos de crear, creamos otro directorio llamado “polls”, y aquí crearemos un archivo “index.html”. En otras palabras, nuestra plantilla debería estar en “polls/templates/polls/index.html”. Como la carga de plantillas está basada en “app_directories”, como ya os explicamos en la parte VII de este tutorial, nos podemos referir a esta plantilla en “Django” simplemente como “polls/index.html”.

Hasta aquí el capítulo de hoy. Os invitamos como siempre, a que sigáis explorando este framework y probando. Os recomendamos que hagáis un repaso de los capítulos anteriores para tener fresca toda la información. Y para todos los que se acaban de incorporar indicarles que tenemos un índice con todos los capítulos del curso, ya que nunca es tarde para empezar.