template_name and Context in CBVs

Setting template_name Explicitly

template_name overrides Django's automatic template-path guess, letting you point a class-based view at any template file you choose.

Example: Setting template_name Explicitly

template_name tells BookListView to render catalog/all_books.html instead of the default books/book_list.html.

from django.views.generic import ListView
from .models import Book


class BookListView(ListView):
    model = Book
    template_name = 'catalog/all_books.html'

Adding Extra Context with get_context_data

Overriding get_context_data() lets a class-based view pass additional variables to the template beyond the default object or queryset, as long as the parent's context is preserved first.

Note: Always call super().get_context_data(**kwargs) before adding new keys, or you lose the built-in context the view normally provides.

Example: Adding Extra Context with get_context_data

The template can now use {{ total_books }} alongside the usual object_list, because both are in the returned dict.

from django.views.generic import ListView
from .models import Book


class BookListView(ListView):
    model = Book

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context['total_books'] = Book.objects.count()
        return context

Using the Extra Context in a Template

Any key added inside get_context_data() becomes a normal template variable, usable with the standard {{ }} syntax exactly like any built-in context value.

Example: Using the Extra Context in a Template

total_books comes from the overridden get_context_data(); object_list still comes from ListView's default behavior.

<p>Total books in catalog: {{ total_books }}</p>
{% for book in object_list %}
  <p>{{ book.title }}</p>
{% endfor %}