CAPÍTULO 4 · Una interfaz que el equipo pueda mantener
Componer una vista sin cargarle todas las responsabilidades
Al preparar las pantallas descubrimos que varias necesitan señalar una sección activa o añadir un mismo dato al contexto. La solución más inmediata sería copiar el método en cada vista. Pero acabamos de aprender por qué esa repetición se vuelve costosa, y tampoco queremos una clase enorme que intente resolver todas las diferencias de todas las páginas.
Los mixins permiten añadir comportamientos pequeños a una clase que ya cumple su función principal. Para usarlos con criterio estudiamos el orden de resolución de métodos y lo que significa continuar la cadena mediante super(). La composición solo funciona si las piezas cooperan; el nombre del mixin debe ayudar a reconocer qué responsabilidad está agregando.
Más adelante aplicaremos esta idea a controles de acceso, con el ciclo de autenticación adecuado. Ahora podemos producir contexto sin duplicar vistas completas. El siguiente lugar donde la repetición se hace visible ya no es Python: aparece en el HTML de las pantallas, que necesitan compartir una estructura sin convertirse en copias independientes.
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 cadena cooperativa de trabajo
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Vista compuesta. Combina comportamiento
- Mixin. Añade una responsabilidad
- super(). Continúa según MRO
- Contexto. Conserva lo aportado por las bases
01 / EL PROBLEMA
¿Para qué sirve?
Una vista puede necesitar navegación, contexto y auditoría. Un mixin pequeño permite combinarlos con diferentes clases base.
02 / COMPRENDER
El concepto, explicado
El MRO decide qué método se ejecuta al usar herencia múltiple. super() continúa esa cadena y no significa simplemente “llamar a mi padre directo”.
Un mixin cooperativo recibe la misma firma y llama super. Su nombre debe decir qué aporta y no ocultar múltiples responsabilidades.
03 / CONSTRUIR
Implementación paso a paso
- Identifica una función transversal.
- Usa firmas compatibles.
- Coloca el mixin antes de TemplateView.
- Comprueba el contexto final y el MRO.
04 / APLICAR
Ejemplo en SensorHub
from django.views.generic import TemplateView
class SectionContextMixin:
section = None
def get_context_data(self, **kwargs):
context = super().get_context_data(**kwargs)
context["active_section"] = self.section
return context
class SensorPage(SectionContextMixin, TemplateView):
section = "sensores"
template_name = "catalogo/sensors.html"
print(SensorPage.__mro__)Cómo leer el ejemplo
- super conserva el contexto producido por TemplateView.
- La vista concreta solo configura section y template.
- La academia aplica el mismo principio con CourseContextMixin.
Error habitual
Omitir super puede eliminar contexto o validaciones de otra clase sin producir un error evidente.
05 / PRACTICAR
Tu turno
Crea otro mixin que agregue breadcrumbs y combínalo con SectionContextMixin.
Ver solución orientativa
Ambos get_context_data llaman super y agregan claves propias; la prueba verifica que active_section y breadcrumbs están presentes.
06 / VERIFICAR
Cómo sabes que funciona
- La clase compuesta conserva el comportamiento de todos los mixins.
- Cada mixin tiene una sola responsabilidad identificable.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Templates, includes y context processors →Continuar en modo relato