Templating & View Rendering: How It Actually Works

A route (Chapters 2–3) tells a framework which piece of code should handle a request. That code usually needs to produce HTML — and almost nobody builds that HTML by hand-concatenating strings. A template engine exists to do that job instead: take a template (mostly literal HTML, with a few placeholders) and a real data context, and produce the final markup. This chapter builds one from scratch, and along the way runs directly into the single most important design decision every real template engine has to make correctly: what happens to a value the moment it gets dropped into HTML.

The Basic Job: Interpolating Data Into a Template

At its simplest, a template engine finds placeholders in a string and replaces them with real values from a context dictionary — the same regex-substitution shape Chapter 2's own router used for dynamic path segments, applied here to a whole document instead of a URL:

This is a real, working template engine — and it's already enough for a page with no user-controlled data on it. The moment a real value from outside the program (a form field, a username, a URL parameter) reaches this function, it stops being safe.

The Real Security Problem Naive Interpolation Creates

render() above doesn't know or care what a value contains — it converts it to a string and drops it straight into the output, verbatim. That's fine for a plain word like "World". It's a genuine, verified vulnerability the moment the value itself contains real HTML:

Auto-Escaping By Default, With an Explicit "Safe" Opt-Out

The fix is to convert any HTML-significant characters (<, >, &, quotes) in a value into their harmless text equivalents before inserting it — Python's own standard library already does exactly this, verified directly:

Escaping every value by default closes the vulnerability above — but it also breaks the genuine, legitimate case where a value really is trusted HTML on purpose (the output of a Markdown-to-HTML converter, say). Real template engines solve this the same way: escape everything automatically, and require an explicit, deliberate opt-out for the rare value that's already known to be safe:

Rerunning the exact same malicious input from the previous section through this new function, unchanged and un-marked, closes the vulnerability directly:

Control Flow: Loops, Parsed Once Into a Real Node Tree

Real templates need more than variable substitution — they need to repeat a chunk of markup once per item in a list. That means the engine needs a real, structured representation of the template, not just one big regex pass over the whole string. The standard approach is a tree of small node objects, each one responsible for rendering its own piece:

A small compile_to_tree() function walks a raw template string once and builds this tree — splitting literal text into TextNodes, variable references into VarNodes, and a matched {% for x in y %}...{% endfor %} block into one ForNode holding its own already-parsed body:

Template Inheritance: extends & block

Most real pages share a common layout — a header, a footer, a nav bar — with only a small region genuinely different per page. Repeating that shared layout in every single template file is exactly the kind of duplication a real engine avoids: a parent template declares named, overridable regions, and a child template extends it, supplying content only for the regions it actually wants to change:

Rendering the child means finding every {% block name %}...{% endblock %} pair it defined, then substituting each one into the matching block in the parent — leaving any block the child never mentioned untouched, with the parent's own default content intact:

Reusing a Parsed Template: Walking a Tree vs. Compiling to Real Code

Every version built so far in this chapter parses the template once and renders it separately — but "reuse the parsed result" still leaves a real design question open: once parsed, how should the engine actually turn that parsed form back into output text, over and over, on every request? Two real, documented strategies answer this differently.

The ForNode-based tree built earlier in this chapter is a working example of the first strategy — walk a tree of node objects, calling .render() down through it. This is exactly how Django's own real template engine works, per Django's own official documentation:

The second real strategy skips the tree entirely and instead compiles the template into real, executable Python source code, generated once and handed to exec():

Both real designs verified above genuinely avoid re-parsing the raw template string on every render — the difference is entirely in what gets reused: a tree of objects walked node by node, or a generated Python function called directly. Comparing both of those against the naive, worst-case mistake this chapter opened with — a hand-rolled engine that reparses the raw string from scratch on every single call — gives a real, measured sense of what each choice actually costs:

Where This Course Is Headed

Chapter 5 takes the real syntax and design questions raised here and compares them directly across five real template systems: Django Templates and Jinja2 (both covered above, now with real syntax alongside the internal design already established here), ERB's embedded-Ruby approach, Laravel's Blade (whose real @extends/@section directives are a direct, named parallel to this chapter's own extends/block mechanism), EJS and Pug, and JSX — whose real model, component composition instead of template inheritance, and built-in escape-by-default {expression} syntax, is a genuinely different answer to the exact two problems this chapter spent the most time on.

Hands-On Exercises