Personal Catalogue: Django & PostgreSQL — Chapter 5, Exercise 3
====================================================

TASK
Explain why the label-swapping JavaScript from this chapter is not,
and cannot be, a substitute for the server-side validation the
ModelForm already provides.

SOLUTION

WHAT THE JAVASCRIPT ACTUALLY CONTROLS

The updateLabels() function reads the currently selected item type and
changes the text content of two <label> elements - "Creator" becomes
"Author" or "Artist" or "Director" depending on the selection. This is
purely a change to what text is displayed on the page. It does not
touch the underlying form field names, does not add or remove any
validation rules, and does not change what value actually gets
submitted when the form's Submit button is pressed.

WHY THIS CAN NEVER BE A SUBSTITUTE FOR SERVER-SIDE VALIDATION

JavaScript running in a browser is entirely under the control of
whoever is using that browser. It can be disabled outright (in which
case the labels simply never update, but the form still submits with
its real, underlying field names unchanged), or a user could bypass
the browser interface entirely and submit a raw HTTP POST request
directly to the /add/ URL, with any field values they choose,
completely independent of what any client-side script would have
displayed or allowed.

WHAT ACTUALLY ENFORCES THE REAL RULES

The ItemForm's own server-side validation - inherited automatically
from the Item model's own field definitions in Chapter 2, such as
release_year's PositiveSmallIntegerField constraint - runs entirely on
the server, using the actual submitted data, regardless of what
JavaScript did or didn't run in the browser beforehand. This is the
one and only place real data integrity is actually enforced; the
label-swapping script exists purely to make the same underlying form
more pleasant and less confusing to fill in correctly, not to add or
replace any of that enforcement.

ANSWER: The label-swapping JavaScript only changes the text displayed
next to form fields - it never touches the field names, validation
rules, or what data is actually accepted on submission. Because
JavaScript can be disabled or bypassed entirely by submitting a request
directly, it can never be relied on for real validation; only the
ModelForm's own server-side checks, which run against whatever data was
actually submitted regardless of the browser's own behavior, can
genuinely enforce the project's data rules.

WHY THIS WORKS AS AN ANSWER
----------------------------
It distinguishes what the JavaScript actually does (display text) from
what it doesn't do (change submitted data or validation), and explains
the specific reason client-side code can never be trusted for
enforcement (it runs entirely under the user's own control and can be
bypassed).