Menu
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?
306
A context processor is a Python function that takes the request object as an argument and returns a dictionary that gets added to the request context. They come in handy when you need to make something available globally to all templates.
Middleware is a framework of hooks into Django's request/response processing. It's a light, low-level “plugin” system for globally altering Django's input or output. Each middleware component is responsible for doing some specific function.
A context is a variable name -> variable value mapping that is passed to a template. Context processors let you specify a number of variables that get set in each context automatically – without you having to specify the variables in each render() call.
context_processors is a list of dotted Python paths to callables that are used to populate the context when a template is rendered with a request. These callables take a request object as their argument and return a dict of items to be merged into the context.
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:
Django Flowchart
User requests a page
Request reaches Request Middlewares, which could manipulate or answer the request
The URLConffinds the related View using urls.py
View Middlewares are called, which could manipulate or answer the request
The view function is invoked
The view could optionally access data through models
All model-to-DB interactions are done via a manager
Views could use a special context if needed
The context is passed to the Template for rendering
63
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
