Exercise 2: Explicit Recursion vs. Implicit Cascade — Possible Solution
====================================================================

HOW movePage() RECOMPUTES full_path
------------------------------
Per this chapter, movePage() first updates the moved page's own parent_id and recomputes its own full_path directly from the new parent's full_path plus its own slug, then saves that change. It then calls updateDescendantPaths(), which iterates over the page's children, recomputes each child's full_path from the page's own now-updated full_path plus the child's slug, saves each child, and recurses into that child's own children - walking the entire subtree beneath the moved page.

HOW THIS DIFFERS FROM DJANGO'S BREADTH-FIRST save() RE-TRIGGER
------------------------------
Per this chapter, Django Rebuild 10 achieved the same result through an implicit mechanism - its own Page model overrides save() so that every time a node is saved, it recomputes its own full_path from its own parent. Moving a page then works by re-triggering save() on every descendant in breadth-first order, letting each node's own overridden save() logic recompute its own path without any code explicitly walking or knowing about the tree structure. Laravel's Eloquent has no equivalent built-in cascade for a computed field like this, so the Laravel version writes the tree walk explicitly and recursively in updateDescendantPaths() instead of relying on an overridden save() to do it implicitly.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly describes movePage()'s own two-step process (updating the moved page, then recursing through updateDescendantPaths()), and correctly explains that Django achieves the same outcome implicitly through a re-triggered save() cascade while Laravel does it through an explicit, hand-written recursive walk.