Exercise 3: Why a before_save Callback — Possible Solution
====================================================================

WHY full_path IS COMPUTED IN A CALLBACK
------------------------------
Per this chapter, before_save :compute_full_path runs automatically every time a Page record is saved, recomputing full_path from the current parent's own full_path plus this page's own slug. Because it's a model-level callback rather than logic living in whatever controller or script happens to create or update a page, full_path is guaranteed to be recalculated correctly no matter where in the application a Page gets saved from - a console session, a background job, an admin form, or a future feature not yet written.

WHY THIS IS SAFER THAN SETTING IT DIRECTLY EACH TIME
------------------------------
Per this chapter, if full_path had to be set directly by whatever code created or updated a page, every single call site would need to remember to compute it correctly and consistently - an easy rule to forget or get wrong in just one place, silently producing a page with a stale or incorrect full_path. Centralizing the computation in the model itself removes that responsibility from every caller.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that the before_save callback runs automatically on every save regardless of where the save originates, and correctly explains why centralizing this logic in the model is safer than requiring every caller to compute full_path correctly on their own.