django template context processor

Let’s talk about context processors and see how you can use them effectively in your Django projects.

“A context processor has a simple interface: it’s a Python function that takes one argument, an HttpRequest object, and returns a dictionary that gets added to the template context. Each context processor must return a dictionary.

Custom context processors can live anywhere in your codebase as long as they are pointed to by the context_processors argument of Engine.” — Django’s documentation

When working with multiple and separate views, you may load different data objects into different views, but sometimes the use case requires you to have the same data available across the entire application — by that, I mean across all templates of the application. What would you do in that case? A beginner might repeat the process of loading data into a template context for each view, which is not so clever, right?

That’s exactly where custom context processors can be very useful.

We’ll see how we can put them in practice in just a moment, but let’s define a use case that would let you easily grasp what we’re about to implement.

Use Case

You’re working on a course management system or LMS and you need to implement a search bar for available course subjects, and that search bar should be available across the entire application. For the sake of this quick tutorial, we’ll simply make the data available inside an HTML <option> or <ul> tag to list all the available subjects.

If you’re an intermediate Django developer, you’re probably aware of the Django template language, but don’t worry if you aren’t. Just remember that Django gives you the ability to create a base template and then add others by simply extending the base one. This is where you usually load all the static files. I included the link so you can look it up.

Implementation

To create a custom context processor, add a new file inside your app folder. We’ll call it custom_context_processor.py:

$ touch your_app/custom_context_processor.py

Now, let’s import our model and define our function:

from .models import Subjectdef subject_renderer(request):
    return {
       ‘all_subjects’: Subject.objects.all(),
    }

This is as simple as it gets. You might be wondering, “How on earth?” Yes, it’s that simple.

Let’s walk back to the definition so you’ll see how easy it is.

A context processor is an interface:

• subject_renderer(request): A Python function that takes one argument which is a request object.
• all_subject: A list of available subjects returned as a dictionary.

That’s it for our context processor implementation and this is enough for our use case.

Now to make it accessible inside our templates, we need to add it inside our templates’ context, so open settings.py and add it like so:

We’ve made the function available across all our templates. It’s now time to render inside the _base.html and display the list of subjects:

You can now navigate across all your application templates, and all your subjects will still be visible or accessible.

I hope this was simple enough. Feel free to leave a response if that wasn’t the case. I’ll be happy to walk you through it again.