{{--
    Bookings listing — docs/wireframes-v12/booking-management.html, content
    region for content region.

    v12's order, top to bottom: the stat strip, an action row, then ONE card
    carrying the `.filter-bar` and the `.data-table` — the filters are the
    card's own header strip (border-bottom), not a card of their own. That is
    the shape every v12 management page uses, and it is the shape
    projects/index.blade.php and inquiries/index.blade.php already draw.

    ## Three deliberate departures from the wireframe

      * **The ₹ Revenue Booked stat card is dropped** (client: "financial not
        required", CR-8 §1), so the strip is a `.grid-3` rather than the
        wireframe's `.grid-4`. Nothing on this screen mentions money.
      * **The All Status select is removed, and the listing IS confirmed-only**
        (CR-9 §3.3, decision D11). CR-8 dropped the wireframe's "Showing
        confirmed bookings only." line as a contradiction of the All Status
        dropdown printed right below it, and defaulted to every status so a user
        could find their own draft. The user then removed the draft outright and
        moved cancelled bookings onto their own screen — so the line is true
        again, the dropdown has nothing left to choose between, and both it and
        its `filter_status` parameter are gone.
      * **An "Add Booking" button is added** above the card. The wireframe's
        action row is an empty flex row with nothing in it; every other v12
        management page puts its primary action there, and a listing with no way
        to add a row is a screen the module cannot be used from.

    ## No lang file (CR-8 §0.1)

    Every string on this screen is written here, on the client's instruction.
    Do not extract them.

    DataTables drives the table. Its own search box stays out of the dom string
    because the wireframe's search input in the filter bar is the one the user
    sees; the wiring below feeds the plugin from it, with the same 300ms
    debounce and the same preXhr filter parameters projects and inquiries use.

    The table markup and its configuration both come from the html builder, so
    the column list exists in exactly one place: BookingsDataTable::getColumns().
--}}
@extends('layouts.app')

@section('title', 'Booking Management')

@section('breadcrumbs')
    <x-breadcrumbs :items="['Booking Management' => null]" />
@endsection

@section('content')
    {{-- Stat strip. v12 tints the icon chip per tile and writes the sub-line as
         a `.stat-change` with an arrow; the three here are the wireframe's own
         first three tiles with their own icons and tones, and every figure is
         computed (BookingController::stats()) rather than mocked.

         **The numbers themselves carry no colour**, exactly as
         booking-management.html:76-93 writes them: on this page the colour
         lives on `.stat-icon` and on `.stat-change`, and the `.stat-value` is
         plain. (The projects listing DOES tint its numbers — its own wireframe
         writes `style="color: var(--success)"` on them — so the two screens
         differ because the pack does, not because one of them is wrong.)

         The Cancelled tile's sub-line carries `.down`, which is v12's red — a
         cancellation rate is a number you want small, so the arrow pointing
         down is the right reading even though the value itself is not a change
         over time. --}}
    <div class="grid-3 mb-4">
        <div class="stat-card">
            <div class="stat-icon blue"><i class="fa-solid fa-file-contract" aria-hidden="true"></i></div>
            <div class="stat-value">{{ $stats['total'] }}</div>
            <div class="stat-label">Total Bookings</div>
            <div class="stat-change up"><i class="fa-solid fa-arrow-up" aria-hidden="true"></i> {{ $stats['this_month'] }} this month</div>
        </div>
        <div class="stat-card">
            <div class="stat-icon green"><i class="fa-solid fa-circle-check" aria-hidden="true"></i></div>
            <div class="stat-value">{{ $stats['active'] }}</div>
            <div class="stat-label">Active</div>
            <div class="stat-change up"><i class="fa-solid fa-arrow-up" aria-hidden="true"></i> {{ $stats['active_pct'] }}% of total</div>
        </div>
        <div class="stat-card">
            <div class="stat-icon red"><i class="fa-solid fa-circle-xmark" aria-hidden="true"></i></div>
            <div class="stat-value">{{ $stats['cancelled'] }}</div>
            <div class="stat-label">Cancelled</div>
            <div class="stat-change down"><i class="fa-solid fa-arrow-down" aria-hidden="true"></i> {{ $stats['cancelled_pct'] }}% cancellation</div>
        </div>
    </div>

    {{-- v12 puts the primary action on its own row above the listing card, at
         the right edge, and leaves an empty div on the left. The empty div is
         kept: `.justify-between` needs two children to push the button right,
         and the button is gated, so without it a view-only user would get a
         bare row rather than no row at all. --}}
    @can('bookings.create')
        <!-- <div class="d-flex justify-between align-center mb-4">
            <div></div>
            <a href="{{ route('bookings.create') }}" class="btn btn-primary">
                <i class="fa-solid fa-plus" aria-hidden="true"></i>Add Booking
            </a>
        </div> -->
    @endcan

    <div class="card">
        {{-- The filter bar IS the card's header strip in v12. It is a <form>
             here only so Enter does not reload the page; `.filter-bar` is the
             flex row, so the form element carries it directly.

             v12 labels none of these five controls — a placeholder and an
             option list are all it draws. The visually-hidden labels are ours
             and are not a visual change: a select whose only name is its first
             option is unusable with a screen reader, and two bare date inputs
             are unusable with one either way.

             Order is the wireframe's: search, project, status, date-from,
             date-to. --}}
        <form id="bookings-filters" class="filter-bar" onsubmit="return false;">
            <div class="search-input">
                <i class="fa-solid fa-search" aria-hidden="true"></i>
                <label class="visually-hidden" for="bookings_filter_search">Search by booking ID, Booking Name, unit...</label>
                <input type="search" id="bookings_filter_search" class="form-control"
                       placeholder="Search by booking ID, Booking Name, unit..." autocomplete="off" />
            </div>

            <label class="visually-hidden" for="bookings_filter_project">All Projects</label>
            <select id="bookings_filter_project" class="form-control filter-select">
                <option value="">All Projects</option>
                @foreach ($projects as $projectId => $projectName)
                    <option value="{{ $projectId }}">{{ $projectName }}</option>
                @endforeach
            </select>

            {{-- **No status select** (CR-9 §3.3, decision D11). It was
                 commented out in CR-8 and is now removed outright, along with
                 the `filter_status` parameter it fed: this listing draws
                 confirmed bookings and only those, so the control would have
                 offered five statuses that filter nothing. A cancelled booking
                 is on /cancellations, and drafts no longer exist. --}}

            <label class="visually-hidden" for="bookings_filter_date_from">From Date</label>
            <input type="date" id="bookings_filter_date_from" class="form-control filter-date"
                   aria-label="From Date" />

            <label class="visually-hidden" for="bookings_filter_date_to">To Date</label>
            <input type="date" id="bookings_filter_date_to" class="form-control filter-date"
                   aria-label="To Date" />
        </form>

        {{-- `table-wrapper` is v12's own scroll box. `table-responsive` rides
             along because it is Bootstrap's name for the same thing and the one
             the shared <x-datatable> component and its test both use; this
             screen does not go through that component (v12's card has no
             card-body around the table) but the two names stay together so a
             later reader does not read the difference as meaningful. --}}
        <div class="table-wrapper table-responsive">
            {{-- yajra's own <table> element. `{!! !!}` because it IS markup;
                 the builder emits a table shell built from getColumns(), and no
                 row data passes through here at all — the rows arrive later as
                 JSON. --}}
            {!! $dataTable->table(['class' => 'data-table']) !!}
        </div>
    </div>
@endsection

@push('styles')
    {{-- DataTables is not in the Metronic bundles — plugins.bundle.js carries
         jQuery and nothing else of the plugin. It is vendored under
         public/assets/plugins/custom/datatables (see VERSIONS.md there) rather
         than pulled from a CDN, because a strict CSP is planned. --}}
    <link href="{{ asset('assets/plugins/custom/datatables/dataTables.bootstrap5.min.css') }}" rel="stylesheet" type="text/css" />
@endpush

@push('scripts')
    {{--
        Order is load bearing: jQuery (plugins.bundle.js, already in the layout)
        → core library → the Bootstrap 5 integration that patches its renderers
        → yajra's init, which calls $(…).DataTable(…) and would throw without
        the two above.
    --}}
    <script src="{{ asset('assets/plugins/custom/datatables/dataTables.min.js') }}"></script>
    <script src="{{ asset('assets/plugins/custom/datatables/dataTables.bootstrap5.min.js') }}"></script>

    {{-- yajra's init script — a <script> element, so escaping it would print
         the source instead of running it. It is built from the html() builder's
         own configuration and carries no row data. --}}
    {!! $dataTable->scripts() !!}

    <script>
        // Wire the filter bar to the table. The four controls are not
        // DataTables columns, so they ride along as extra ajax parameters on
        // preXhr; the search box drives the plugin's own global term, which the
        // filterColumn() on `code` spreads across the code, the main customer's
        // name and the unit number.
        //
        // The html builder registers the instance on window.LaravelDataTables
        // keyed by table id, and its own init script runs on DOMContentLoaded,
        // so this listener has to wait for the same event.
        document.addEventListener('DOMContentLoaded', function () {
            var registry = window.LaravelDataTables || {};
            var table = registry['kt_bookings_table'];

            if (!table) {
                return;
            }

            var search = document.getElementById('bookings_filter_search');
            var controls = [
                'bookings_filter_project',
                'bookings_filter_date_from',
                'bookings_filter_date_to',
            ]
                .map(function (id) { return document.getElementById(id); })
                .filter(Boolean);

            table.on('preXhr.dt', function (event, settings, data) {
                controls.forEach(function (control) {
                    data[control.id.replace('bookings_filter_', 'filter_')] = control.value;
                });
            });

            controls.forEach(function (control) {
                control.addEventListener('change', function () { table.ajax.reload(); });
            });

            if (search) {
                var pending = null;
                search.addEventListener('input', function () {
                    window.clearTimeout(pending);
                    pending = window.setTimeout(function () {
                        table.search(search.value).draw();
                    }, 300);
                });
            }
        });
    </script>
@endpush