3.3. Cómo procesa una petición Django

Debemos señalar varias cosas en lo que hemos visto. Este es el detalle de lo que sucede cuando ejecutas el servidor de desarrollo de Django y hacemos una petición a una página Web.

• El comando python manage.py runserver importa un archivo llamado settings.py desde el mismo directorio. Este archivo contiene todo tipo de configuraciones opcionales para esta instancia de Django en particular, pero una de las configuraciones más importantes es ROOT_URLCONF. La variable ROOT_URLCONF le dice a Django qué módulo de Python debería usar para la URLconf de este sitio Web. ¿Recuerdas cuando django-admin.py startproject creó el archivo settings.py y urls.py? Bueno, el settings.py generado automáticamente tenía un ROOT_URLCONF que apunta al urls.py generado automáticamente. ¡Qué conveniente!
• Cuando llega una petición — digamos, una petición a la URL /time/ — Django carga la URLconf apuntada por la variable ROOT_URLCONF. Luego comprueba cada uno de los patrones de URL en la URLconf en orden, comparando la URL solicitada con un patrón a la vez, hasta que encuentra uno que coincida. Cuando encuentra uno que coincide, llama a la función de vista asociada con ese patrón, pasando un objeto HttpRequest como primer parámetro de la función. (Veremos más de HttpRequest luego).
• La función de vista es responsable de retornar un objeto HttpResponse.

Conoces ahora lo básico sobre cómo hacer páginas Web con Django. Es muy sencillo, realmente — sólo tenemos que escribir funciones de vista y relacionarlas con URLs mediante URLconfs. Podrías pensar que es lento enlazar las URL con funciones usando una serie de expresiones regulares, pero te sorprenderás.

3.3.1. Cómo procesa una petición Django: Detalles completos

Además del mapeo directo de URLs con funciones vista que acabamos de describir, Django nos provee un poco más de flexibilidad en el procesamiento de peticiones.

El flujo típico — resolución de URLconf a una función de vista que retorna un HttpResponse — puede ser corto-circuitado o augmented mediante middleware. Los secretos del middleware serán tratados en profundidad en el Capítulo15, pero un esquema (ver Figura 3-1) te ayudará conceptualmente a poner todas las piezas juntas.

Figura 3.1 El flujo completo de un petición y una respuesta Django

Cuando llega una petición HTTP desde el navegador, un manejador específico a cada servidor construye la HttpRequest, para pasarla a los componentes y maneja el flujo del procesamiento de la respuesta.

El manejador luego llama a cualquier middleware de Petición o Vista disponible. Estos tipos de middleware son útiles para augmenting los objetos HttpRequest así como también para proveer manejo especial a determinados tipos de peticiones. En el caso de que alguno de los mismos retornara un HttpResponse la vista no es invocada.

Hasta a los mejores programadores se le escapan errores (bugs), pero el middleware de excepción ayuda a aplastarlos. Si una función de vista lanza una excepción, el control pasa al middleware de Excepción. Si este middleware no retorna un HttpResponse, la excepción se vuelve a lanzar.

Sin embargo, no todo está perdido. Django incluye vistas por omisión para respuestas amigables a errores 404 y 500.

Finalmente, el middleware de respuesta es bueno para el procesamiento posterior a un HttpResponse justo antes de que se envíe al navegador o haciendo una limpieza de recursos específicos a una petición.