Challenge 2: Use a Policy in a Blade View — Possible Solution
====================================================================

<!-- resources/views/books/show.blade.php -->

@extends('layouts.app')

@section('content')
  <h1>{{ $book->title }}</h1>
  <p>{{ $book->description }}</p>
  <p>Price: ${{ $book->price }}</p>

  @can('update', $book)
    <a href="{{ route('books.edit', $book) }}">Edit this book</a>
  @endcan

  @cannot('update', $book)
    <p><em>You don't have permission to edit this book.</em></p>
  @endcannot
@endsection

WHY THIS WORKS
--------------
- @can('update', $book) checks the EXACT SAME BookPolicy::update()
  method (from the chapter's example) that $this->authorize('update',
  $book) would check server-side in a controller — the same
  authorization LOGIC is reused for two different purposes: enforcing
  the rule (in the controller) and deciding what to SHOW in the UI (in
  the view).
- Because @can passes the specific $book instance, the Edit link only
  renders for users who actually own THIS particular book — a different
  user viewing the same page (who doesn't own this book) simply never
  sees the link at all, rather than seeing a link that would fail with a
  403 if clicked.
- @cannot is the inverse directive, useful here to show a friendly
  message explaining WHY no edit link is visible, rather than just
  silently omitting it — though omitting it entirely (no @cannot block)
  would also be a perfectly reasonable choice depending on the desired
  UX.
- It's worth noting that hiding the Edit link in the UI is a courtesy,
  not a security boundary on its own — the REAL enforcement still needs
  to happen server-side via $this->authorize() in the controller
  (Challenge 1), since a user could still navigate directly to the edit
  URL even if the link were hidden.