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:

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.