Exercise 3: Model Events vs. an Overridden save() — Possible Solution
====================================================================

WHAT A "MODEL EVENT" MEANS IN THIS CONTEXT
------------------------------
Per this chapter, Eloquent fires a whole family of events during a model's lifecycle - creating, created, saving, saved, deleting, and more - and code can register a closure to run automatically whenever one of those specific events occurs, without modifying the model's own core methods at all. static::saving(function (Page $page) {...}) registers a closure that Eloquent will call automatically every single time a Page is about to be saved, regardless of where in the codebase that save was triggered from.

WHY THIS IS USED INSTEAD OF OVERRIDING save() DIRECTLY
------------------------------
Per this chapter, Django achieves the identical practical result (recomputing full_path before persisting) by directly overriding the save() method itself - replacing Django's own default save behavior with custom logic that also calls the original behavior. Laravel's model-events approach achieves the same practical outcome through a genuinely different mechanism: rather than replacing or wrapping Eloquent's own internal save() logic, it registers a separate listener that Eloquent's own unmodified save() process calls out to automatically at the right moment. The model's actual save() method itself is never touched or overridden at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that a model event is a lifecycle hook Eloquent fires automatically (rather than a method being overridden), and correctly contrasts this event-listener mechanism with Django's own direct save() override, even though both approaches produce the identical practical result of recomputing full_path before every save.