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

TASK
Trace through exactly what selector_context() does when a request hits
/gameweeks/5/fixtures/, explaining how it correctly resolves gameweek
5's own season for the season dropdown even though the function's own
signature never receives a season_id directly.

SOLUTION

1. Django's own URL resolver matches /gameweeks/5/fixtures/ against
   the fixture_entry view's URL pattern, which captures 5 as
   gameweek_id. Before the view even runs, Django records this match
   as request.resolver_match, with gameweek_id = "5" (as a string,
   since it comes straight from the URL) available in
   request.resolver_match.kwargs.

2. fixture_entry itself runs, queries the database, and renders
   predictor/fixture_entry.html using render(). At this point, Django
   builds the full template context — running every registered context
   processor, selector_context() included — before the template is
   actually rendered.

3. Inside selector_context(request), the line
   request.resolver_match.kwargs.get('gameweek_id') reads the exact
   same gameweek_id ("5") that was captured during URL resolution in
   step 1. Since it's not None, the function takes the
   "gameweek_id present" branch rather than falling back to the global
   is_current season.

4. It queries Gameweek.objects.filter(pk=gameweek_id) — pk=5 —
   with select_related('season'), fetching gameweek 5's own real row
   together with its related Season row in one query. current_season
   is set to that gameweek's own real season, not any globally-flagged
   "current" one.

5. gameweeks is then built by filtering Gameweek.objects on that
   specific current_season, so the season dropdown's own gameweek
   options are always the ones belonging to whichever season gameweek
   5 actually is part of — even if that season is not the one flagged
   is_current in the database at all (for example, an old, completed
   season being browsed after a new one has started).

6. The returned context dict merges into the template's context
   automatically, so _selector.html's own {% for season in all_seasons %}
   loop can mark the right <option> as selected using
   {% if season == current_season %}, with no view function anywhere
   needing to explicitly say "this page belongs to season X."

The key mechanism throughout is that request.resolver_match.kwargs
carries the URL's own captured parameters forward into the context-
processor stage automatically, purely because Django's own request
object is shared across the whole request-response cycle — the
context processor doesn't need season_id in its own function
signature because it can read gameweek_id directly off the request
it's already handed, and derive the season from that.

WHY THIS WORKS AS AN ANSWER
----------------------------
It traces the full real sequence in order (URL resolution setting
resolver_match, the context processor reading it during template
context construction, the actual database query resolving the season)
and explains precisely why request.resolver_match — not the function's
own parameters — is what lets selector_context() know which URL
produced the current request.