CAPÍTULO 4 · Una interfaz que el equipo pueda mantener
La siguiente pantalla debe sentirse parte de la misma aplicación
Una vez que podemos preparar el contexto, aparece la tarea de mostrarlo. El catálogo, el histórico y la configuración necesitan contenidos distintos, pero comparten navegación, estilos y una manera de orientar al usuario. Si cada pantalla incluye su propia copia del encabezado, cualquier ajuste obliga a recorrerlas todas y alguna puede quedar diferente.
Construimos un template base y extraemos fragmentos cuando tienen una responsabilidad reconocible. Los includes nos permiten compartir componentes; los context processors aportan información común cuando realmente corresponde a varias páginas. No todo debe ser global: conservar las diferencias cerca de la vista que las necesita mantiene comprensible la composición.
La interfaz empieza a tener continuidad visual. Aun así, el HTML no explica por sí solo cómo responderá a una búsqueda, una carga de datos o un error. Para que esa experiencia siga siendo mantenible, los scripts que animan las pantallas necesitan la misma atención que dimos a las vistas del servidor.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Una página construida con piezas
Las flechas muestran responsabilidades relacionadas; no representan un orden obligatorio de ejecución.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Template base. Define estructura compartida
- Includes. Reutilizan fragmentos
- Contexto. Entrega datos de la vista
- Página. Renderiza la composición
01 / EL PROBLEMA
¿Para qué sirve?
Copiar el layout entre páginas vuelve costoso cambiar navegación y estilos. Herencia e includes mantienen estructuras comunes sin una SPA obligatoria.
02 / COMPRENDER
El concepto, explicado
base.html define el layout y bloques. Cada página extiende base y usa includes para componentes reutilizables.
Un context processor aporta datos globales a templates renderizados con request. Evita consultas costosas en cada render si esos datos no se necesitan siempre.
base.html organiza la presentación común con blocks; no es el mismo base.py de configuración. TEMPLATES[0][DIRS] puede apuntar a BASE_DIR / "templates", mientras APP_DIRS descubre templates dentro de apps registradas. Un include reutiliza un fragmento; extends hereda un layout.
03 / CONSTRUIR
Implementación paso a paso
- Define base.html.
- Crea bloques title y content.
- Extrae componentes visuales repetidos.
- Agrega solo contexto global ligero.
04 / APLICAR
Ejemplo en SensorHub
<!-- templates/base.html -->
<!doctype html>
<html lang="es">
<head><title>{% block title %}SensorHub{% endblock %}</title></head>
<body>
{% include "shared/navigation.html" %}
<main>{% block content %}{% endblock %}</main>
</body>
</html>
<!-- catalogo/sensors.html -->
{% extends "base.html" %}
{% block content %}<h1>Sensores</h1>{% endblock %}Cómo leer el ejemplo
- extends evita repetir el documento HTML.
- include comparte un componente, no crea automáticamente lógica de negocio.
- Django escapa variables por defecto; no marques contenido de usuarios como safe sin motivo.
Error habitual
Un context processor que consulta muchas tablas puede encarecer cada página. Usa contexto local para datos específicos.
05 / PRACTICAR
Tu turno
Agrega un breadcrumb solo a la página de sensores.
Ver solución orientativa
Añádelo desde get_context_data de esa vista o desde un mixin, sin consultar sensores en el context processor global.
06 / VERIFICAR
Cómo sabes que funciona
- Un cambio al layout se refleja en todas las páginas.
- Las variables de texto de usuarios se escapan.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Frontend modular y estado explícito →Continuar en modo relato