Con Flask montaste cada pieza de la web de Papyrus a mano: elegiste dónde guardar el catálogo (el JSON de M6), escribiste la validación del POST campo a campo, y si mañana quisieras un panel para que Marta edite libros sin tocar código, tendrías que construirlo. Django es la respuesta de la otra escuela: un framework con baterías incluidas que trae de serie persistencia, panel de administración, formularios validados, gestión de usuarios y más. En esta lección arrancarás un proyecto Django desde cero, entenderás su arquitectura MTV y su estructura de ficheros (que impone, no sugiere), redefinirás el Libro de M5 como un modelo con persistencia regalada y terminarás editando el catálogo desde el admin — sin haber escrito ni una línea de HTML. El mismo Papyrus, el otro camino.

1. Filosofía: baterías incluidas (cuándo Django, cuándo Flask)
2. Instalación y startproject: nace papyrus_web
3. Proyecto vs app: startapp catalogo
4. La estructura de ficheros, fichero a fichero
5. El patrón MTV (y su primo MVC)
6. Primera vista: HttpResponse y urls.py
7. El modelo Libro: de dataclass a models.Model
8. Migraciones: makemigrations y migrate
9. El admin de Django: el regalo estrella
10. runserver y el mapa completo

Flask te da un núcleo mínimo y libertad total; Django te da un electrodoméstico completo y sus instrucciones. Ninguno es "mejor": resuelven contextos distintos.

Regla práctica: si tu proyecto es sobre todo una API o algo pequeño y peculiar, Flask; si es "una aplicación web clásica" — catálogo, altas, usuarios, administración —, Django te ahorra semanas. Papyrus, que es exactamente eso, es un caso de libro (nunca mejor dicho).

En un entorno virtual nuevo (M1: un venv por proyecto):

pip install django instaló también el comando django-admin, el generador de proyectos. startproject papyrus_web crea una carpeta con el esqueleto completo — primera diferencia cultural con Flask, donde empezaste con un app.py vacío: Django te da la estructura hecha porque su filosofía es que todos los proyectos Django se parezcan.

Django distingue dos conceptos que conviene fijar pronto:

• El proyecto (papyrus_web) es el conjunto: configuración global, URLs raíz, el sitio entero.
• Una app es un componente funcional con sus modelos, vistas y plantillas: el catálogo, algún día las reservas, quizá los socios. Un proyecto contiene varias apps; una app bien hecha podría reutilizarse en otro proyecto.

Creamos la primera:

Y la registramos en el proyecto, en papyrus_web/settings.py, para que Django la tenga en cuenta:

Ese INSTALLED_APPS es literalmente la lista de baterías conectadas: fíjate en cuántas cosas vienen encendidas de fábrica.

Tras los dos comandos, el árbol es este (los ficheros importantes, comentados):

Dos ajustes de cortesía en settings.py antes de seguir: LANGUAGE_CODE = "es" y TIME_ZONE = "Europe/Madrid" — el admin te hablará en español.

Django organiza el código según el patrón MTV: Model–Template–View. Es la separación de responsabilidades que venimos practicando desde M3, con nombres propios:

• Model: los datos y las reglas para acceder a ellos. En Papyrus-Flask eran la dataclass más almacen.py más el JSON; en Django será una sola clase.
• Template: la presentación — como las plantillas Jinja2 de 10-02, con una sintaxis casi idéntica.
• View: la lógica que conecta ambos — recibe la petición, consulta modelos, elige plantilla.

Si has oído hablar de MVC (Model-View-Controller), el patrón clásico: es lo mismo con las etiquetas movidas. La "View" de Django hace de Controller del MVC, y el Template hace de "View" del MVC. Confuso de nombrar, idéntico de espíritu: datos, lógica y presentación, cada uno en su sitio.

El "hola mundo" Django, para ver el mecanismo desnudo. En catalogo/views.py:

Dos diferencias con Flask saltan a la vista: la función recibe siempre request como primer parámetro (en Flask era un objeto global que importabas), y no hay decorador de ruta. En Django, las URLs viven separadas de las vistas, en papyrus_web/urls.py:

path(ruta, vista) hace lo que @app.route hacía: apuntar en la tabla. La diferencia es filosófica: Django prefiere todas las URLs juntas en un índice en vez de repartidas por decoradores — en proyectos grandes ese índice único se agradece. Arranca y compruébalo:

http://127.0.0.1:8000 (Django usa el puerto 8000; Flask, el 5000) muestra tu saludo. runserver incluye recarga automática, como el modo debug de Flask — y con la misma advertencia: es un servidor de desarrollo, no de producción.

Aquí llega el momento estrella de la lección. Recuerda la dataclass de M5:

Su reencarnación Django, en catalogo/models.py:

Compara miembro a miembro:

Los mismos tres datos de siempre, los mismos métodos precio_final() y hay_stock() (Hamlet seguirá costando 9.83 para socios — los invariantes de M9 viajan con nosotros). La novedad es lo que no ves: por heredar de models.Model (herencia de M5 en acción), cada Libro sabe guardarse con libro.save() y consultarse con Libro.objects... (lo exprimiremos en 10-05). En Flask escribiste cargar_catalogo y guardar_catalogo sobre JSON; esto es la persistencia que Django te regala. Por debajo usa una base de datos SQLite — un fichero db.sqlite3 en tu proyecto, sin instalar ni configurar nada. La teoría de bases de datos SQL queda fuera de este curso: hoy nos basta con que el regalo funciona. Un detalle profesional de propina: DecimalField evita los redondeos raros del float con dinero — Django hasta mejora nuestra dataclass.

Definir el modelo no crea nada todavía: hay que decirle a la base de datos qué forma tienen los datos. Ese diálogo son las migraciones, en dos pasos:

Conceptualmente:

• makemigrations compara tus models.py con el último estado conocido y escribe la receta del cambio (un fichero Python en migrations/): "crear la tabla de Libro con estas columnas".
• migrate aplica las recetas pendientes a la base de datos real.

Es control de versiones para la forma de tus datos: cada cambio futuro del modelo (añadir un campo autor, por ejemplo) generará su migración 0002_..., y cualquier compañero reproduce tu base de datos ejecutando migrate. Verás que la primera vez se aplican también migraciones de admin y auth: son las tablas de las baterías incluidas preparándose.

Y ahora, la demostración de fuerza. Tres líneas en catalogo/admin.py:

Un superusuario para entrar (te pedirá usuario y contraseña por terminal):

Arranca runserver, entra en http://127.0.0.1:8000/admin/, identifícate y contempla: un panel de administración completo — listado de libros, formulario de alta con validación por tipos, edición, borrado con confirmación, buscador — sin haber escrito una sola plantilla ni una sola vista. Da de alta el catálogo canónico: La Odisea (12.50, 4), Hamlet (9.95, 6), El Quijote (15.90, 8) y Fausto (21.00, 10). Marta ya puede gestionar el inventario desde el navegador; en Flask, ese panel te habría costado varias tardes. El __str__ que definimos es lo que el admin muestra en los listados — sin él verías «Libro object (1)».

El ciclo de trabajo Django que repetirás mil veces, resumido:

• Olvidar registrar la app en INSTALLED_APPS: el síntoma clásico es makemigrations respondiendo "No changes detected". Django solo mira las apps registradas.
• Editar models.py y no migrar: al acceder verás OperationalError: no such table. Modelo cambiado = makemigrations + migrate, siempre, en ese orden.
• Confundir django-admin con manage.py: django-admin solo para startproject; después, todo con python manage.py ..., que carga la configuración de tu proyecto.
• Usar FloatField para dinero: la tentación viene de la dataclass. DecimalField existe precisamente para importes; acostúmbrate desde el primer modelo.
• Borrar db.sqlite3 o migrations/ "para arreglar" un error: en aprendizaje puedes permitírtelo, pero es dinamita: pierdes datos e historial. Mejor entender el error — casi siempre es una migración sin aplicar.
• Buscar el if __name__ == "__main__": en Django no arrancas tú la aplicación; la arranca manage.py. Suelta el control: el framework llama a tu código, no al revés (eso es, literalmente, lo que define a un framework).

El catálogo canónico siempre tuvo autores (Homero, Shakespeare, Cervantes, Goethe) y el modelo no los guarda. Añade autor = models.CharField(max_length=100, default="") al modelo, genera y aplica la migración, y completa los autores desde el admin. Ajusta __str__ para mostrar "Hamlet — Shakespeare".

Añade la vista socios (con HttpResponse y HTML mínimo listando a Luis, Marta y Pau con sus carnés LUIS-001, MARTA-002 y PAU-003) y conéctala a la URL /socios/. Compruébala en el navegador.

python manage.py shell abre un intérprete con tu proyecto cargado. Úsalo para recorrer todos los libros e imprimir titulo: precio_final(socio=True). Verifica contra los valores canónicos: 12.35, 9.83, 15.71 y 20.75. (Adelanto inevitable: para "todos los libros" necesitarás Libro.objects.all() — la puerta de 10-05.)

Ejercicio 1:

El default="" es necesario: la base de datos ya contiene libros y Django necesita saber qué poner en la columna nueva de las filas existentes (si no lo das, makemigrations te lo preguntará interactivamente).

Ejercicio 2:

HTML en cadenas otra vez — igual de incómodo que en Flask. Las plantillas Django que lo arreglan llegan en 10-05.

Ejercicio 3:

Los cuatro números canónicos, ahora saliendo de una base de datos en lugar de un JSON. Libro.objects.all() es tu primer QuerySet: la sintaxis completa de consultas te espera en la siguiente lección.

Django ha mostrado sus cartas: una estructura impuesta pero clara (settings.py configura, urls.py enruta, views.py responde, models.py define los datos), el patrón MTV separando datos, lógica y presentación, y sobre todo las baterías — el modelo Libro que heredando de models.Model gana la persistencia que en Flask programaste a mano sobre JSON, las migraciones que versionan la forma de tus datos, y ese admin que convirtió a Marta en gestora del inventario con tres líneas de código. La dataclass de M5 y el modelo Django son el mismo libro con distinta cubierta: mismos datos, mismos precio_final() y hay_stock(), mismos 12.35, 9.83, 15.71 y 20.75. Pero de momento los visitantes solo ven un HttpResponse con HTML incrustado: nada de catálogo navegable, ni búsquedas, ni altas públicas. En la próxima lección completaremos la app: consultas con QuerySets, plantillas con herencia (te sonarán muchísimo), formularios con ModelForm que validan solos, y la web de Papyrus terminada por segunda vez — misma funcionalidad, dos caminos, y tú sabiendo recorrer ambos.