Mini análisis de Django

Django es un en entorno de programación web que lleva varios años funcionando aunque ha sido ahora (2009) cuando ha visto un auge importante en su uso debido a la salida de la primera versión estable, la 1.0. En este artículo quiero dar una visión general y resumida de como está estructurado y como funciona, sin meterme en sintáxis, así como mi opinión personal-profesional. Es importante destacar que este artículo no es un curso ni un tutorial de Django, aunque sin duda tener unas nociones de como funciona Django en conjunto ayudará al que a continuación quiera aprenderlo a fondo.

Proyectos y aplicaciones

En Django tenemos los conceptos de proyectos y aplicaciones. Un proyecto engloba varias aplicaciones y las hace trabajar juntas para producir el resultado que ve el usuario, generalmente un portal web. Por ejemplo juanjoalvarez.net es un proyecto Django que está compuesto de aplicaciones para la interfaz de administración, blog, enlaces, comentarios, gestión de imágenes, visualización de mis artículos compartidos de Google Reader, visualización de mis tweets en Twitter, incrustación de objetos de la BBDD dentro de artículos (por ejemplo imágenes), exportación de feeds RSS y etiquetas (es probable que me deje algo.) Algunas de estas aplicaciones son de terceros (blog, imágenes, feeds del Google Reader, etiquetas, incrustación de objetos), otras venían con Django “de serie” (comentarios, interfaz de administración, exportación de RSS), otros los he desarrollado yo (Twitter y en el futuro cercano aplicación de reviews culturales) y otros los he mejorado (blog, incrustación). Es importante destacar el poco solapamiento que existe a priori entre estas aplicaciones (en cualquier momento puedo meter nuevas o sacar alguna existente sin afectar a los demás) y sin embargo lo fácil que es integrarlas.

Resumen de modo de operación de Django

El modo de operación real de Django es realmente más complejo de lo que voy a explicar aquí; sin embargo en este resumen se puede ver el flujo de los componentes principales usando un ejemplo realista. En diez pasos voy a especificar los pasos que daría el sistema desde que el usuario pincha en un link a “http://juanjoalvarez.net/blog” (o lo escribe en la barra de direcciones del navegador) hasta que visualiza la página ya cargada uno o dos segundos después.

  1. Cuando llega una petición a Django, por ejemplo un usuario carga http://juanjoalvarez.net/blog en su navegador, el servidor web (Apache normalmente) intercepta la petición y se la pasa a Django.

  2. Django obtiene la parte de la ruta (en éste caso /blog) y consulta un fichero interno llamado urls.py en el que básicamente se listan una serie de expresiones regulares (sencillas, generalmente) que asocian determinados patrones a las funciones Python que manejarán la petición que concuerde con ese patrón. Por ejemplo en mi fichero urls.py estará especificado que si la ruta es exactamente /blog/ el manejador deberá ser la función Python list_posts(category="blog").

  3. La función Python que maneja una petición (en Django se denominan vistas) recibe los parámetros que Django le pasa, que como vemos en este caso sería category="blog". También puede recibir, aunque en este caso no lo haga, un parámetro page que usaremos más tarde para definir en que página, de haber varias, se ha de iniciar la lista de artículos. Además Django automáticamente le pasa un objeto request con toda la información de la petición que ha realizado el navegador (como versión del navegador, cookies, parámetros GET y POST, sistema operativo, etc, etc, etc.)

    En el caso del ejemplo el parámetro category especifica que categorías de entradas se tienen que mostrar; cuando escribo un artículo entre los datos que introduzco (titular, texto, idioma, fecha de publicación, etc.) está el de las categorías a las que pertenece el mismo. Por ejemplo este mismo artículo pertenece a las categorías “articles”, “software libre” y “programación” (si bajas al final del texto del artículo las podrás ver y pinchar sobre ellas.) También existe la categoría “all” que mostraría todos los artículos sin importar la categoría a la que pertenezcan

    Siguiendo con el ejemplo, la categoría blog en este caso la aplico a entradas de lo que podría considerarse un blog como historias de mi vida o chorradas varias que no interesan a nadie (las cosas que pueden tener cierto interés como ésta las meto en “artículos”.) Al recibir éste parámetro la función Python list_posts() sabe que sólo debe mostrar las entradas que pertenezcan a esta categoría, de modo que usando una llamada le dice al ORM “dame todas las entradas que pertenezcan a la categoría blog”.

  4. El ORM, que es una capa intermedia por encima de la BBDD real (MySQL en este caso), proporciona una interfaz para acceder a la BBDD como si tratáramos con objetos. Al recibir la petición “dame todas las entradas que pertenezcan a la categoría blog” internamente va a hacer una consulta sobre la BBDD y obtendrá todos los registros de la tabla django_post. Pero en lugar de devolver esos registros en un diccionario, como hacen interfaces más primitivas a BBDD, lo que hace es crear un objeto Post por cada uno, inicializar ese objeto y cargar sus miembros con los valores del registro (realizando las conversiones pertinentes en cada caso de valores de BBDD y tipos Python), y genera estructuras de datos para acceder fácilmente a las claves externas y las relaciones muchos<=>muchos usando una interfaz Pythonica y sencilla.

    Además el ORM de Python (como cualquier otro buen ORM) no sólo nos permite usar registros de la BBDD como si fueran objetos sino que también nos permite definir éstos registros declarando clases Python, de modo que una versión simplificada de mi objeto Post podría ser:

    from models import *

    class Post(models.Model):
title = CharField(max_length=255)
author = ForeignKey(Author)
entradilla = TextField()
content = TextField()
publish_date = DateTimeField(