Exercise 1: Why the Breadcrumb Is Built in the View — Possible Solution
====================================================================

WHY THE WALK HAPPENS IN PYTHON, NOT DTL
------------------------------
Per this chapter, the Django Template Language deliberately doesn't support arbitrary function calls, real expressions, or general-purpose logic - there's no way to write a genuine loop-that-walks-upward-an-unknown-number-of-times directly inside a template file. Building the breadcrumb requires exactly that: starting at the current page and following node.parent upward until reaching the top, with no way to know in advance how many levels that will take (it could be one level or five). That kind of open-ended, arbitrary-depth logic is precisely what DTL was never designed to express, so it has to live in the view instead, where full Python is available.

WHAT THIS ILLUSTRATES ABOUT "THIN TEMPLATES"
------------------------------
Per this chapter's own central finding, this split - a real, arbitrary Python loop in the view; a simple, flat {% for %} in the template - is Django's "thin templates" philosophy made concrete. The view does all the genuinely tricky work (the unbounded upward walk) and hands the template an already-completed, flat list. The template's own job is trivial by comparison: it only ever iterates over a list that already exists, never capable of performing that walk itself. This is a deliberate design choice, not a missing feature - keeping templates incapable of arbitrary logic execution is exactly what prevents a template-injection-style vulnerability from becoming possible in the first place.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that DTL structurally cannot express the arbitrary-depth walk the breadcrumb requires, and correctly connects this to the "thin templates" philosophy - real logic in the view, simple iteration in the template - as a deliberate security/separation-of-concerns choice rather than an accidental limitation.