Ver índice de contenidos del libro

15.3. Métodos de un Middleware

Ahora que sabes qué es un middleware y cómo instalarlo, echemos un vistazo a todos los métodos disponibles que las clases middleware pueden definir.

15.3.1. Inicializar: init(self)

Utiliza __init__() para realizar una configuración a nivel de sistema de una determinada clase middleware.

Por razones de rendimiento, cada clase middleware activada es instanciada sólo una vez por proceso servidor. Esto significa que __init__() es llamada sólo una vez — al iniciar el servidor — no para peticiones individuales.

Una razón común para implementar un método __init__() es para verificar si el middleware es en realidad necesario. Si __init__() emite django.core.exceptions.MiddlewareNotUsed, entonces Django elimina el middleware de la pila de middleware. Esta característica se puede usar para verificar si existe una pieza de software que la clase middleware requiere, o verificar si el servidor esta ejecutándose en modo debug, o cualquier otra situación similar.

Si una clase middleware define un método __init__(), éste no debe tomar argumentos más allá del estándar self.

15.3.2. Pre-procesador de petición: process_request(self, request)

Éste método es llamado tan pronto como la petición ha sido recibida — antes de que Django haya analizado sintácticamente la URL para determinar cuál vista ejecutar. Se le pasa el objeto HttpRequest, el cual puedes modificar a tu voluntad.

process_request() debe retornar ya sea None o un objeto HttpResponse.

  • Si devuelve None, Django continuará procesando esta petición, ejecutando cualquier otro middleware y la vista apropiada.
  • Si devuelve un objeto HttpResponse, Django no se encargará de llamar a cualquier otro middleware (de ningún tipo) o a la vista apropiada. Django inmediatamente devolverá ése objeto HttpResponse.

15.3.3. Pre-procesador de vista: process_view(self, request, view, args, kwargs)

Éste método es llamado después de la llamada al pre-procesador de petición y después de que Django haya determinado qué vista ejecutar, pero antes de que ésa vista sea realmente ejecutada.

La siguiente tabla muestra los argumentos que se pasan a esta vista:

Argumento Explicación
request El objeto HttpRequest
view La función Python que Django llamará para manejar esta petición. Este es en realidad el objeto función en sí, no el nombre de la función como string
args La lista de argumentos posicionales que serán pasados a la vista, no incluye el argumento request (el cual es siempre el primer argumento de una vista)
kwargs El diccionario de palabras clave argumento que será pasado a la vista

Así como el método process_request(), process_view() debe retornar ya sea None o un objeto HttpResponse.

  • Si devuelve None, Django continuará procesando esta petición, ejecutando cualquier otro middleware y la vista apropiada.
  • Si devuelve un objeto HttpResponse, Django no se encargará de llamar a cualquier otro middleware (de ningún tipo) o a la vista apropiada. Django inmediatamente devolverá ése objeto HttpResponse.

15.3.4. Pos-procesador de respuesta: process_response(self, request, response)

Éste método es llamado después de que la función de vista es llamada y la respuesta generada. Aquí, el procesador puede modificar el contenido de una respuesta; un caso de uso obvio es la compresión de contenido, como por ejemplo la compresión con gzip del HTML de la respuesta.

Los parámetros deben ser bastante auto-explicativos: request es el objeto petición, y response es el objeto respuesta retornados por la vista.

A diferencia de los pre-procesadores de petición y vista, los cuales pueden retornar None, process_response() debe retornar un objeto HttpResponse. Esa respuesta puede ser la respuesta original pasada a la función (posiblemente modificada) o una totalmente nueva.

15.3.5. Pos-procesador de excepción: process_exception(self, request, exception)

Éste método es llamado sólo si ocurre algún error y la vista emite una excepción sin capturar. Puedes usar este método para enviar notificaciones de error, volcar información postmórtem a un registro, o incluso tratar de recuperarse del error automáticamente.

Los parámetros para esta función son el mismo objeto request con el que hemos venido tratando hasta aquí, y exception, el cual es el objeto Exception real emitido por la función de vista.

process_exception() debe retornar ya sea None o un objeto HttpResponse.

  • Si devuelve None, Django continuará procesando esta petición con el manejador de excepción incorporado en el framework.
  • Si devuelve un objeto HttpResponse, Django usará esa respuesta en vez del manejador de excepción incorporado en el framework.

Nota Django trae incorporado una serie de clases middleware (que se discuten en la sección siguiente) que hacen de buenos ejemplos. La lectura de su código debería darte una buena idea de la potencia del middleware.

También puedes encontrar una serie de ejemplos contribuidos por la comunidad en el wiki de Django.