Hi, {{ user.username }}.
Cart ({{ cart_count }}) ``` A view that renders the about page does not mention the cart: ```python def about(request): return render(request, "about.html", {"title": "About"}) ``` `about.html` extends `base.html`. During `render()`, Django calls `cart_count`, merges `{"cart_count": 3}` into the context, and the header shows 3\. The `title` from the view is still there. With `render()`, the view's dictionary wins a name clash. Avoid the names `user`, `request`, `messages`, and `perms`. A `RequestContext` you construct by hand is the exception: a processor can overwrite keys you passed into the constructor. `render()` and `TemplateResponse` push the view's dictionary on afterwards. An API view that returns `JsonResponse` never builds a `RequestContext`, so `cart_count` never runs for that request. A redirect or a file download skips it too. A unit test can call the function without rendering a template. `RequestFactory` builds a request without session middleware, and this processor only calls `.get` on whatever object sits at `request.session`, so a dict stands in for the session: ```python from django.test import RequestFactory from store.context_processors import cart_count def test_cart_count_sums_quantities(): request = RequestFactory().get("/") request.session = {"cart": {"1": 2, "2": 1}} assert cart_count(request) == {"cart_count": 3} ``` --- ## When it is the right place Use a context processor when the variable shows up in a shared template, usually `base.html` or an include that many pages pull in. The value comes from the request: the user, the session, a header, the path. Computing it is cheap, or it stays lazy until the template actually reads it. A queryset assigned in the dictionary is still lazy. `Category` here is only an illustration. This version does not hit the database until a template loops over `nav_categories`: ```python from store.models import Category def navigation(request): return { "nav_categories": Category.objects.filter(in_nav=True), } ``` Django calls `navigation` on every `render()`, including the about page, whose template never mentions `nav_categories`. `filter()` only builds the queryset. Django puts that object in the context, and the query waits. The SQL runs if a template loops over `nav_categories`. The about page never mentions the variable, so that query never runs. `list(queryset)` and `queryset.count()` send the SQL while `navigation` is still running. So does a dictionary you fill in the function, by looping over the categories and copying out names and urls. That work is done when the function returns. Every `render()` pays for it, including pages that never print the result. If that cost is high and only a few pages need the value, pass it from those views. The about page's title belongs in the about view. A processor for it would also run on the cart page, the homepage, and every other `render()` call, to fill a variable a single template reads. [Tracking YouTube Video Watch Progress with Django](https://developer-service.blog/tracking-youtube-video-watch-progress-with-django/) does the same with `video_id` and `progress`. The `video_detail` view passes both, because only that page needs them. --- ## Where middleware starts Middleware and context processors are both dotted paths in settings, and both receive the request. Take the same request for the about page. Middleware runs first, on the way in. `SessionMiddleware` loads the session. `AuthenticationMiddleware` sets `request.user`. Middleware may also return a response immediately and skip the view, or change the response on the way out: a header, a cookie, a redirect. The view runs next. `about` calls `render()`. Context processors run inside that `render()`, after middleware has prepared the request and before the HTML goes back out. Then middleware runs again, on the way out, and sees the `HttpResponse` the view returned. The messages framework uses both. `MessageMiddleware` attaches the message storage to the request and writes it onto the response on the way out. The messages context processor reads that storage and exposes it as `messages`. Drop the processor, and a view can still call `messages.success()`, while `{% for message in messages %}` in the template renders nothing. You could compute the cart count in middleware and hang it on the request. The class would live in `store/middleware.py`: ```python class CartCountMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): cart = request.session.get("cart", {}) request.cart_count = sum(cart.values()) return self.get_response(request) ``` Placing it after `SessionMiddleware`, so `request.session` exists: ```python MIDDLEWARE = [ # ... "django.contrib.sessions.middleware.SessionMiddleware", "store.middleware.CartCountMiddleware", # ... ] ``` It then runs for every request that reaches Django, including the JSON endpoint that never renders a template. The header still has no `{{ cart_count }}`, because this class set an attribute on the request. With the `request` processor enabled, the template can read `{{ request.cart_count }}`. Leave that processor out, and the template has no path to the attribute. A redirect is the kind of job [The Importance of Django Middleware](https://developer-service.blog/the-importance-of-django-middleware/) gives this layer. If a signed-in user has not accepted the current terms, that middleware sends them to the acceptance page before the view runs. A context processor never sees that choice. It runs only if a template is rendered. The next time a header variable is missing on one page and present on another, open the `context_processors` list before you copy the queryset into a second view. --- ## Conclusion `{{ user }}` is in every template because a context processor returns it. A variable of your own follows the same path: a function that takes the request, a dictionary, and a dotted path in `TEMPLATES`. Leave a value in the view when one page needs it. Put it in a context processor when a shared template needs it and the work stays cheap, or waits until the template reads it. Put it in middleware when it has to happen before the view runs, or when the request or the response has to change for HTML and JSON alike. --- Follow me on Twitter: [https://twitter.com/DevAsService](https://twitter.com/DevAsService?ref=developer-service.blog) Follow me on Instagram: [https://www.instagram.com/devasservice/](https://www.instagram.com/devasservice/?ref=developer-service.blog) Follow me on TikTok: [https://www.tiktok.com/@devasservice/](https://www.tiktok.com/@devasservice/?ref=developer-service.blog) Follow me on YouTube: [https://www.youtube.com/@DevAsService](https://www.youtube.com/@DevAsService?ref=developer-service.blog)