Mata tus formularios hardcodeados: cómo la generación de formularios basada en JSON cambió mi forma de construir aplicaciones Django

Todo desarrollador de Django conoce el ritual. Defines un modelo. Luego escribes un ModelForm. Luego ajustas los widgets. Luego añades un layout crispy. Luego el cliente dice "añade un campo" y tocas cuatro archivos. Luego dice "haz que ese campo sea condicional" y añades JavaScript. Luego dice "el mismo formulario, pero en un modal" y duplicas una plantilla.

Multiplica esto por 20 modelos y estarás manteniendo un pequeño ejército de clases de formulario, cada una ligeramente distinta, cada una codificada a mano, cada una desincronizándose silenciosamente del modelo que representa.

Choqué con este muro en dos proyectos muy distintos - un sistema industrial de control de calidad de fabricación y un back office de trading financiero - y llegué a la misma solución en ambas ocasiones: dejar de escribir clases de formulario y empezar a escribir configuraciones de formulario.

Un campo de formulario de Django es en realidad solo un conjunto de propiedades: un nombre, un tipo, un widget, una etiqueta, si es obligatorio, qué opciones tiene. No hay nada en esa descripción que requiera la definición de una clase de Python. Son datos, y los datos pertenecen a una estructura de datos.

La idea es sencilla: define los campos como diccionarios, almacénalos en un esquema y deja que una única clase de formulario genérica se construya a sí misma a partir de ese esquema en tiempo de ejecución.

Todo el sistema se apoya en una única clase. Mapea identificadores de cadena a clases de campo y clases de widget de Django, y luego itera sobre el esquema para construirse a sí misma:

Ese es todo el motor. Cada tipo de campo de Django, cada tipo de widget, mapeados mediante búsqueda por cadena. Un nuevo formulario es un nuevo diccionario, no una nueva clase.

El primer proyecto fue un sistema de datos de producción para un fabricante industrial. Los inspectores de calidad siguen Procedimientos Operativos Estándar (SOP) que requieren medir dimensiones específicas, verificar tratamientos de superficie y registrar resultados de aprobado/reprobado para cada etapa de producción.

El desafío: más de 20 formularios de inspección diferentes, cada uno con campos únicos específicos del tipo de pieza de trabajo y del paso del SOP. La inspección de un torno vertical de placa terminal mide cosas diferentes que la inspección de fresado de una placa bipolar.

Con formularios codificados a mano, eso son más de 20 clases de formulario, cada una con sus propias definiciones de campo, su propia validación, sus propias peculiaridades de plantilla. Con el enfoque de blueprints, son más de 20 diccionarios y una sola clase de formulario.

Los datos recopilados se almacenan como JSON en un JSONField, conservando tanto las etiquetas de los campos como sus valores. Esto significa que el registro de inspección es autodescriptivo: puedes leerlo sin saber qué esquema lo generó.

El segundo proyecto llevó el patrón más lejos. Un back office de trading de criptomonedas necesitaba formularios para cuentas, comisiones, perfiles de riesgo, estado de cumplimiento, planes de tarifas; cada uno con campos distintos, permisos distintos, métodos de envío distintos (POST para crear, PATCH para actualizaciones masivas) y contextos de renderizado distintos (página completa, modal, en línea).

Aquí el blueprint creció más allá de las definiciones de campos hasta convertirse en una especificación completa del formulario:

Fíjate en lo que está codificado en ese único diccionario: el método HTTP, el endpoint de la API, el tamaño del modal, qué campos requieren qué permisos, de dónde cargar las opciones de los desplegables, el layout de rejilla de Bootstrap y el mensaje de éxito. Eso es toda una experiencia de formulario en datos puros.

La plataforma financiera añadió una función potente: control de permisos por campo. Cada campo del blueprint puede declarar una cadena de permiso. El renderizador de formularios comprueba los permisos del usuario actual y se degrada de forma elegante:

Los usuarios sin el permiso ACCOUNT_COMMISSION_UPDATE ven el campo de la tasa de comisión, pero es de solo lectura y aparece atenuado. Sin plantilla aparte, sin bloques {% if perms.x %}, sin lógica de renderizado condicional. El blueprint declara la regla, el renderizador la aplica.

Las listas de opciones estáticas están bien para desplegables de "Cualificado/No cualificado", pero un selector de moneda necesita extraer datos de una API en vivo. El blueprint gestiona esto con dos propiedades:

• api_choices: un nombre de URL de Django que devuelve las opciones
• api_choices_autocomplete: habilita Select2 con búsqueda del lado del servidor

El motor de formularios resuelve el nombre de la URL, obtiene las opciones en el momento del renderizado y conecta el autocompletado de Select2 si está configurado. El autor del blueprint nunca escribe JavaScript: simplemente declara dónde viven los datos.

Después de construir dos aplicaciones grandes con este patrón, puedo articular con exactitud lo que te aporta:

1. Añadir un formulario es añadir datos, no código. Una nueva inspección de QC o un nuevo tipo de cuenta es un nuevo diccionario. Ninguna clase nueva, ninguna plantilla nueva, ninguna URL nueva. El sistema lo descubre y lo renderiza.
2. Cambiar un formulario es cambiar un solo sitio. ¿La etiqueta de un campo está mal? Cambia el diccionario. ¿Necesitas una nueva opción en el desplegable? Actualiza la lista de opciones. ¿Necesitas hacer un campo opcional? Establece "required": False. Un archivo, un cambio, hecho.
3. Los formularios se vuelven portátiles. Un blueprint es solo un diccionario. Puedes serializarlo a JSON, almacenarlo en una base de datos, cargarlo desde un archivo de configuración o enviarlo a través de una API. Al motor de formularios no le importa de dónde vino el esquema.
4. La consistencia es automática. Cada formulario pasa por la misma canalización de renderizado. Los atributos de los widgets, las clases CSS, el comportamiento del diseño: todo está estandarizado por el motor, no copiado y pegado entre clases de formulario.
5. Almacenamiento de datos autodescriptivo. Cuando los datos del formulario se guardan como JSON con etiquetas y valores, el registro almacenado es legible por humanos sin necesidad de consultar el esquema. Los informes y las exportaciones se vuelven triviales.
6. Los mixins de validación se componen con limpieza. El formulario dinámico sigue siendo un formulario de Django. Puedes añadir mixins para validaciones específicas del dominio (comprobaciones de existencia de piezas de trabajo, validación de permisos) sin tocar el esquema.

Los formularios dinámicos no siempre son la elección correcta. Para un formulario de inicio de sesión con dos campos, un ModelForm es más simple y más claro. Pero el patrón brilla cuando:

• Tienes muchos formularios similares con distintos conjuntos de campos (inspecciones de control de calidad, pasos de incorporación, páginas de encuestas)
• Los formularios necesitan ser configurables sin cambios de código - por administradores, por clientes o por sistemas externos
• Necesitas control de campos basado en permisos a lo largo de muchos formularios sin duplicar la lógica de plantillas
• Los datos del formulario necesitan almacenarse como JSON autodescriptivo en lugar de en columnas fijas de la base de datos
• Estás construyendo una plataforma con múltiples inquilinos que cada uno necesita formularios ligeramente distintos

El coste inicial es una clase DynamicForm (unas 50 líneas) y la disciplina de definir esquemas en lugar de clases de formulario. La recompensa es un sistema en el que añadir el formulario número 21 cuesta el mismo esfuerzo que añadir el segundo.