Context processors vs middleware in django

Go To


It seems to me that everything a context processor can do, middleware can do. So what's the point of context processors? Are they just middleware-lite?

2012-04-04 04:31
by garageàtrois


Middleware acts as a hook into Django's request/response processing at a low level and it is light. The hooks are available for request, response, view, template_response, and exception processing. The hook might need to modify the request before the view handles it, it might need to log information about the request for debugging purposes, check a cookie to set the local, and so on.

Read more on Middleware.

Context processors just modify the context. Context is a key value mapping with variables passed to a template. A context processor takes a request object as its argument, and returns a dictionary of items that get merged into the context. The context gets rendered to your template as per your view and it attaches whatever else your context processors merge in. You can think of it as a global context variable(s), available to you at all your templates.

Read more on Context Processors.

Both are fairly simple to write and have their purpose. Here is a diagram that shows where middleware and context fit in in a typical django flow:

enter image description here

Django Flowchart

  1. User requests a page

  2. Request reaches Request Middlewares, which could manipulate or answer the request

  3. The URLConffinds the related View using

  4. View Middlewares are called, which could manipulate or answer the request

  5. The view function is invoked

  6. The view could optionally access data through models

  7. All model-to-DB interactions are done via a manager

  8. Views could use a special context if needed

  9. The context is passed to the Template for rendering

2014-10-23 03:09
by radtek
I like that flowchart. However there's a small flaw: the arrow between Model and Template should be between View and Template instead - m0etaz 2018-10-08 15:48
It may go through to the template, but the data is coming form in this cas - radtek 2018-10-09 15:26
sure, but there's no direct connection between models and templates (unless you access models using templatetags, which i don't think is a good idea - m0etaz 2018-10-09 15:28
No its not direct, the context is built at the view from data from models. This is a simplified high level flow to help users understand - radtek 2018-10-09 15:30


Context processors are used to provide the templates with extra data. Middleware is for intercepting the request/response objects, and modifying them (or triggering other behaviour) in some meaningful way.

2012-04-04 04:34
by Josh Smeaton


They work in different level of stack for different context. Its normally hard to keep stacks of a framework to be absolutely orthodox, especially the only thing a web framework like Django processing are request and response. Yes, we could use request.user, instead of context.user by context_processor when rendering template. But you might don't want attributes which are only used in template, are set on every request.

Also, decorator is flexible than middleware for view-level operation, but its hard to say middleware is a decorator-lite. I'd like to treat context processors as assignment template tags but loaded automatically, by the way.

2012-04-04 05:26
by okm