Django es un miembro importante de una nueva generación de frameworks Web. ¿Y qué significa ese término exactamente?
Para contestar esa pregunta, consideremos el diseño de una aplicación Web escrita usando el estándar Common Gateway Interface (CGI), una forma popular de escribir aplicaciones Web alrededor del año 1998. En esa época, cuando escribías una aplicación CGI, hacías todo por ti mismo — el equivalente a hacer una torta desde cero —. Por ejemplo, aquí hay un script CGI sencillo, escrito en Python, que muestra los diez libros más recientemente publicados de una base de datos:
#!/usr/bin/python
import MySQLdb
print "Content-Type: text/html"
print
print "<html><head><title>Libros</title></head>"
print "<body>"
print "<h1>Los ultimos 10 libros</h1>"
print "<ul>"
conexion = MySQLdb.connect(user='yo', passwd='dejame_entrar', db='mi_base')
cursor = conexion.cursor()
cursor.execute("SELECT nombre FROM libros ORDER BY fecha_pub DESC LIMIT 10")
for fila in cursor.fetchall():
print "<li>%s</li>" % fila[0]
print "</ul>"
print "</body></html>"
conexion.close()
Este código es fácil de entender. Primero imprime una línea de Content-Type
,
seguido de una línea en blanco, tal como requiere CGI. Imprime HTML
introductorio, se conecta a la base de datos y ejecuta una consulta que
obtiene los diez libros más recientes. Hace un bucle sobre esos libros y
genera una lista HTML desordenada. Finalmente imprime el código para cerrar el
HTML y cierra la conexión con la base de datos.
Con una única página dinámica como esta, el enfoque desde cero no es
necesariamente malo. Por un lado, este código es sencillo de comprender —
incluso un desarrollador novato puede leer estas 16 líneas de Python y
entender todo lo que hace, de principio a fin —. No hay más nada que aprender;
no hay más código para leer. También es sencillo de utilizar: tan sólo guarda
este código en un archivo llamado ultimoslibros.cgi
, sube ese archivo a un
servidor Web y visita esa página con un navegador.
Pero a medida que una aplicación Web crece más allá de lo trivial, este enfoque se desmorona y te enfrentas a una serie de problemas:
¿Qué sucede cuando múltiples páginas necesitan conectarse a la base de datos? Seguro que ese código de conexión a la base de datos no debería estar duplicado en cada uno de los scripts CGI, así que la forma pragmática de hacerlo sería refactorizarlo en una función compartida.
¿Debería un desarrollador realmente tener que preocuparse por imprimir
la línea de Content-Type
y acordarse de cerrar la conexión con la base
de datos? Este tipo de código repetitivo reduce la productividad del
programador e introduce la oportunidad para que se cometan errores. Estas
tareas de configuración y cierre estarían mejor manejadas por una
infraestructura común.
¿Qué sucede cuando este código es reutilizado en múltiples entornos, cada uno con una base de datos y contraseñas diferentes? En ese punto, se vuelve esencial alguna configuración específica del entorno.
¿Qué sucede cuando un diseñador Web que no tiene experiencia programando en Python desea rediseñar la página? Lo ideal sería que la lógica de la página — la búsqueda de libros en la base de datos — esté separada del código HTML de la página, de modo que el diseñador pueda hacer modificaciones sin afectar la búsqueda.
Precisamente estos son los problemas que un framework Web intenta resolver. Un framework Web provee una infraestructura de programación para tus aplicaciones, para que puedas concentrarte en escribir código limpio y de fácil mantenimiento sin tener que reinventar la rueda. En resumidas cuentas, eso es lo que hace Django.