Exercise 1: A Genuine Third Architectural Option — Possible Solution
====================================================================

WHAT A RAILS HELPER MODULE IS
------------------------------
Per this chapter, a Helper is a plain Ruby module living in app/helpers/, whose methods are automatically made available inside every view without any explicit import or registration. PagesHelper#breadcrumb_for is defined there and called directly from the ERB template as breadcrumb_for(@page).

WHY IT DIFFERS FROM DJANGO'S "BUILD IT IN THE VIEW" APPROACH
------------------------------
Per this chapter, Django's own Chapter 4 built its breadcrumb walk directly inside the view function because there was nowhere else idiomatic to put it - Django has no dedicated, separate layer specifically for view-supporting logic the way Rails does.

WHY IT DIFFERS FROM LARAVEL'S "BUILD IT IN THE CONTROLLER BY CONVENTION" APPROACH
------------------------------
Per this chapter, Laravel's own Chapter 4 built the same logic inside the Controller, but only by convention, not necessity - Blade's own @php directive would technically have allowed the same logic to live directly inline in the template instead. Laravel doesn't have a distinct, purpose-built layer separate from both the Controller and the template the way Rails' Helpers are.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly describes what a Rails Helper module is and how it's used, and correctly explains that Rails' Helpers layer is a genuinely separate, first-class architectural option that neither Django (which had no alternative to the view) nor Laravel (which used the Controller only by convention) offers in quite the same way.