Django Template Basics

1. From HttpResponse to Templates: The "T" in MTV

So far, our views have looked something like this:

from django.http import HttpResponse

def say_hello(request):
    return HttpResponse("<h1>Hello World</h1>")

While you can embed HTML directly, this becomes messy and unmaintainable for anything more than a single line. Imagine trying to manage a complex webpage with hundreds of lines of HTML inside a Python string!

This is where Django's template system comes in. It allows you to create separate .html files that contain your page structure and presentation. Your view's job then shifts from generating HTML itself to preparing data and telling Django which template to render with that data.

This separation of concerns is at the heart of the MTV pattern:

• Model: Manages the data (we'll cover this soon).
• View: Contains the business logic, preparing the data.
• Template: Defines the presentation, or how the page looks.

The diagram below shows where Templates fit into the full request-response cycle. The View receives a request, interacts with the Model, and then passes data to the Template to generate the final HTML response.

2. Setting Up the Template System

Before we can render a template, Django needs to know where to find it. You need to perform two key steps:

1. Create a directory to store your HTML files.
2. Tell Django where this directory is located.

While there are a couple of ways to organize templates, the most robust and scalable method is to create a templates directory inside each application. To prevent naming conflicts (e.g., two different apps having an index.html), we add another subdirectory named after the app itself.

This creates a namespace for your templates. For our playground app, the structure will be:

playground/
├── templates/
│   └── playground/
│       └── hello.html
└── views.py

Let's watch a short video that walks through creating this structure and configuring Django to use it.

3. Rendering a Template with render()

With our template file in place, we can now update our view to render it. Django provides a convenient shortcut function called render() for this exact purpose.

The render() function takes the request object, the name of the template, and an optional dictionary of data (called context) to pass to the template. It handles loading the template, filling it with the data, and returning a properly formatted HttpResponse object.

This is explained well in the official Django documentation.

Now, let's put this into practice. We'll continue with the video tutorial, which shows how to modify your view to use render().

After these changes, your say_hello view in playground/views.py should now look like this:

from django.shortcuts import render

def say_hello(request):
    # This view now renders an HTML file instead of returning inline text.
    return render(request, 'playground/hello.html')

If you run your server and visit http://127.0.0.1:8000/playground/hello/, you should see the content of your hello.html file rendered in the browser!

4. Reusing Layouts with Template Inheritance

You'll quickly notice that many pages on a site share common elements like a header, navigation bar, and footer. Copying and pasting this HTML into every single template is inefficient and violates the DRY (Don't Repeat Yourself) principle.

Django's template engine solves this with inheritance. You can create a parent base.html template that defines the overall page structure and includes special "blocks" that child templates can override.

• {% extends "app_name/base.html" %}: This tag, placed at the top of a child template, declares which parent template it inherits from.
• {% block block_name %} and {% endblock %}: These tags are used in the parent template to define sections that can be filled in by child templates. The child template then uses the same block tags to provide its unique content.

This is one of the most powerful features of the template system. Let's see how it works.

After following the video, your files should look something like this:

playground/templates/playground/base.html

<!DOCTYPE html>
<html>
<head>
    <title>My Django Site</title>
</head>
<body>
    <main>
        {% block content %}
        <!-- Child template content will go here -->
        {% endblock %}
    </main>
</body>
</html>

playground/templates/playground/hello.html

{% extends 'playground/base.html' %}

{% block content %}
    <h1>Hello World</h1>
    <p>This is my first Django template!</p>
{% endblock %}

Now, any page that extends base.html will automatically share the same document structure. If you need to add a stylesheet or a site-wide navigation bar, you only need to change it in one place: base.html.

Conclusion

Congratulations! You've successfully moved from returning simple text to rendering full HTML pages, a major step in building a web application. You now understand how to separate presentation from logic, a core tenet of backend development.

Key Takeaways:

• Templates separate the presentation layer (HTML) from the logic layer (Python views), aligning with the MTV pattern.
• Django finds templates based on the INSTALLED_APPS setting and the templates/app_name/ directory convention, which provides namespacing.
• The render() function is the standard shortcut to load a template and return an HttpResponse.
• Template inheritance using {% extends %} and {% block %} is a powerful technique for creating reusable page layouts and keeping your code DRY.

Preview of the Next Lesson:
Our templates are still static. The real power of a backend framework is in generating dynamic content—pages that change based on data from a database, user input, or other sources. In the next lesson, "Pass context data from a view to a template and display it," we will explore how to pass data from your views into your templates and use the Django Template Language (DTL) with tags like {{ variable }} and {% for %} to display it.