Challenge 3: Fix Broken Mixin Order — Possible Solution
====================================================================

# BROKEN — mixin listed AFTER the generic view

class BookCreateView(CreateView, LoginRequiredMixin):
    model = Book
    fields = ["title", "price", "author"]
    template_name = "catalog/book_form.html"
    success_url = reverse_lazy("book-list")

# FIXED — mixin listed BEFORE the generic view

class BookCreateView(LoginRequiredMixin, CreateView):
    model = Book
    fields = ["title", "price", "author"]
    template_name = "catalog/book_form.html"
    success_url = reverse_lazy("book-list")

WHY THE BROKEN VERSION DOESN'T RELIABLY ENFORCE THE LOGIN CHECK
--------------------------------------------------------------------
Python resolves methods on a class with multiple inheritance using the
Method Resolution Order (MRO), which walks the list of base classes
LEFT TO RIGHT. When something calls view.as_view() and eventually
view.dispatch(request), Python looks for dispatch() starting with the
FIRST class in the inheritance list.

In `class BookCreateView(CreateView, LoginRequiredMixin)`, CreateView
comes first. CreateView (through its own chain of parent classes, all
the way up to Django's base View) defines its own dispatch() method —
Python finds and uses THAT one, because CreateView appears before
LoginRequiredMixin in the MRO. LoginRequiredMixin's own dispatch()
override — the part of the mixin that actually checks
request.user.is_authenticated and redirects to the login page if not —
never gets a chance to run at all, because CreateView's dispatch() is
found first and Python never continues looking further down the MRO
chain for a class that already provided a matching method.

The practical symptom: an anonymous (logged-out) user hitting this view
would NOT be redirected to the login page — the view's own create logic
would run directly, unprotected, exactly as if LoginRequiredMixin had
never been added at all. This is a quiet failure, not a loud error,
which is what makes it a genuinely dangerous mistake to make in practice.

In the FIXED version, `class BookCreateView(LoginRequiredMixin, CreateView)`,
LoginRequiredMixin comes FIRST in the MRO. Python finds
LoginRequiredMixin's dispatch() first, which checks authentication and
either redirects to login (for anonymous users) or calls
super().dispatch(request) to continue down the chain to CreateView's own
dispatch() (for authenticated users) — the check now genuinely runs
before the view's real logic gets a chance to execute.

WHY THIS WORKS AS A GENERAL RULE
------------------------------------
- Mixins meant to intercept or gate behavior (LoginRequiredMixin,
  PermissionRequiredMixin, and similar) should always be listed FIRST in
  a class's base list, with the actual generic view (CreateView,
  UpdateView, ListView, etc.) listed LAST — this ensures the mixin's
  dispatch() is found first by Python's MRO and gets the opportunity to
  either short-circuit the request or call super().dispatch(...) to
  continue on to the real view logic.