Hace poco empezamos a probar Django, uno de los frameworks web más populares para el lenguaje Python. Nos gustaría compartir las características que nos han parecido impresionantes y algunas que no nos han gustado.
Lo más impresionante: el sitio de administración
El “admin site”, como le llaman los Djangonautas, es más que un simple scaffolding para el back-end, puesto que construye una interfaz más avanzada.
Django puede deducir información de los modelos para generar automáticamente las páginas de administración de los objetos de negocio, desde donde se realizan todas las operaciones sobre base de datos: lectura, actualización, creación, eliminación, validación, relación con otros objetos, etc. Así, los usuarios administradores puedan agregar contenido al sitio y tenerla lista para mostrar a los clientes finales.
En unos pocos pasos, explicados en la parte 2 del tutorial, Django ofrece:
- El widget correcto a utilizar (combobox, textbox, textarea, etc) para cada campo del objeto de negocio en el formulario de creación y edición.
- Atajos inteligentes para los campos: calendarios para las fechas, vínculos de “hoy” y “ahora” para fechas y horas.
Ejemplo de formulario, con validaciones (*)
- Listas desplegables para escoger objetos relacionados (a través de llaves foráneas), con un atajo especial para crear un nuevo objeto relacionado en una ventana pop-up en caso éste no exista todavía.
- Validación de cada uno de los campos por tipo de dato y longitud.
Ejemplo de filtros y campos de búsqueda (*)
- Filtros y criterios de búsqueda para cada objeto, con vínculos de “último mes” y “última semana” para buscar por fecha
- Acciones en masa: seleccionar varios objetos y borrarlos a la vez, cambiarles de estado o cualquier acción definida por el programador
- Historial de acciones por cada usuario
Ejemplo de usuarios, perfiles y roles
- Administración de usuarios, incluyendo perfiles y roles
Una lista bastante larga para un sitio generado automáticamente, ¿no es verdad?
Así, Django nos salva de la tediosa pero infaltable tarea de programar el back-end. Con unas pocas líneas de código, se obtienen páginas listas para mostrar en producción.
(*) Imágenes tomadas del tutorial oficial de Django.
Lo más decepcionante: necesitamos migraciones, ¡urgente!
En Django, un cambio en los modelos no implica un cambio en la base de datos; es decir, el comando ’syncdb’ sólo puede crear tablas, pero no alterar las antiguas.
Los modelos suelen evolucionar con el tiempo, porque cambian los requerimientos o simplemente notamos un error: falta o sobra un campo, o se necesita una tabla extra y una llave foránea. Django no ofrece ningún soporte para estos casos, así que uno se ve obligado a modificar el esquema escribiendo las sentencias SQL a mano. Esto es inconcebible por las siguientes razones:
- Algunos de los casos mencionados podrían implicar pérdida o inconsistencia de datos. Es responsabilidad del framework estar alerta de estos errores y proteger al desarrollador de ellos, especialmente si se trata de un tema tan sensible.
- Cada motor de base de datos maneja su propia versión de SQL, así que una modificación manual no serviría universalmente.
- Una de las tareas de un framework es esconder el lenguaje SQL (es por esto que existen los ORMs).
- Django debería ser capaz de manejar al menos los casos más sencillos, como agregar una columna.
En Ruby on Rails, el framework web más popular para el lenguaje Ruby, existe el concepto de “migración“: es posible manipular el esquema de datos a través de código en Ruby, ya sea para crear tablas, agregar columnas o insertar datos. Esta facilidad ofrece muchas ventajas:
- Abstracción del lenguaje SQL; es decir, una migración es útil inclusive si se usan distintos motores de bases de datos (por ejemplo, uno ligero para desarrollo y uno más potente para producción, o si la aplicación se desplegó en más de un entorno, cada uno con sus requerimientos sobre bases de datos).
- Disponibilidad universal, puesto que las migraciones son archivos que se almacenan en el directorio del proyecto, así que cualquier desarrollador puede acceder a ellas (a través del repositorio) y mantener sincronizada su copia local.
- Uso automatizado, puesto que las migraciones son código fuente ejecutable. Esto no es posible si se usara un gestor gráfico para interactuar con la base de datos.
- Historial de versiones de la base de datos, puesto que se crea una migración por cada transacción. Así, es posible deshacer o aplicar un conjunto de cambios sobre la base de datos, lo que equivale a mantener el esquema de datos bajo control de versiones (repositorio). Esto no es posible si se usara un gestor gráfico.
Migración para crear una tabla
Django necesita algo similar con urgencia. Por el momento, lo más recomendable es comenzar a utilizar el sitio de administración inmediatamente después de definir los modelos, para poder notar errores lo antes posible y no tener que lidiar con la evolución del esquema. Naturalmente, los desarrolladores de Django ya han comenzado a discutir opciones para salvar este error.
Conclusión
Django es un framework que ofrece muchas abstracciones de alto nivel que simplifican enormemente la tarea del desarrollo web. El ejemplo más claro es la generación automática del back-end, que ahorra muchas horas de labor tediosa.
La documentación es excelente. La curva de aprendizaje de Django es muy baja gracias a la cantidad de información disponible acerca de él, muy bien redactada y muy completa.
El manejo del esquema de la base de datos es un señor problema. A menos que uno sea un experto en SQL (cosa que la “mala” costumbre de los ORMs hace improbable), seguro se tendrán problemas al hacer cambios a las tablas, inclusive cambios sencillos.
Fuentes
- Tutorial oficial de Django
- Documentación oficial de Django
- “Schema Evolution”, de la wiki de Django
- “Migrations”, de la documentación de Ruby on Rails
No related posts.
Autor:
Pablo Torres Navarrete
