Premier League Predictor: Django & MySQL — Chapter 10, Exercise 1
====================================================

TASK
Explain why this chapter's selector uses real page navigation plus a
Django context processor rather than a JS CustomEvent the way the
FastAPI/PostgreSQL sibling does, naming the specific architectural
fact about fixture_entry (and every other page in this course) that
makes navigation the more natural choice here.

SOLUTION

The FastAPI sibling's own frontend is built so that a page, once
loaded, fetches its own data (teams, fixtures, predictions) via
JavaScript and renders it into the DOM client-side. Under that
architecture, switching the selected season or gameweek genuinely
needs to update already-rendered content in place without a full page
reload — there's no other way to reflect the new selection, so a
CustomEvent broadcasting the change and letting each script re-fetch
its own data is a reasonable, necessary design.

fixture_entry, and every other page this course has built since
Chapter 4, work completely differently: the view itself queries the
database and renders the full HTML — the team grid, the disabled
buttons, the gameweek label — on the server, before the response is
ever sent to the browser. There's no client-side data-fetching layer
for a CustomEvent to trigger a refresh of, because nothing on the page
was ever rendered by JavaScript in the first place.

Given that, picking a different gameweek doesn't need to update an
existing page at all — it needs to load a different page, one that
Django will render fresh and correctly for that specific gameweek_id,
the exact same way the very first page load already worked. Real
navigation (onchange -> location.href) accomplishes that directly,
with no extra machinery needed. The context processor's own job isn't
to replace the CustomEvent's role of "notify other code that the
selection changed" — since navigating to a new URL already does
that automatically, by loading a whole new, correctly-rendered page —
its job is only to make sure the selector's own dropdown options
(all_seasons, all_gameweeks) are available on every page without each
view needing to fetch and pass them in individually.

WHY THIS WORKS AS AN ANSWER
----------------------------
It identifies the specific architectural fact (fixture_entry, and
every page since, is server-rendered with no client-side data-fetching
layer) that makes a CustomEvent unnecessary here, and explains what
job navigation ends up doing instead (loading a fresh, correctly-
rendered page) versus what the context processor's own separate job
actually is (supplying dropdown data everywhere, not notifying of
selection changes).