{{-- Booking Types listing — docs/wireframes-v12/booking-type.html, content region for content region. The content region of that page is ONE card and nothing else: a `.card-header` carrying the module icon, the heading and the primary Add button, and a `.table-wrapper` with the `.data-table` under it. **No filter bar and no search input** (CR-7 §1, §4). This is where the page departs from the Projects and Inquiries listings, and it departs because the wireframe does: those pages draw a `.filter-bar` as the card's header strip and this one draws a heading row instead. Nothing here feeds a search box, and BookingTypesDataTable sets `searching => false` to match — do not add one without the client asking. The primary action is inside the card header, not on a row above it. Same reason: Projects and Inquiries put it above the card because their card header is the filter bar and has no room; this card's header is a heading row with the button already in it. DataTables drives the table, and both the markup and the configuration come from the html builder, so the column list exists in exactly one place: BookingTypesDataTable::getColumns(). The two dialogs are included once at the foot, and nrems-master-modals.js re-targets the Edit one per row — see partials/modals for why one instance each rather than one per row. --}} @extends('layouts.app') @section('title', __('booking_types.title')) @section('breadcrumbs') {{-- The wireframe's trail is Home / Administration / Booking Types. "Administration" is the sidebar section and has no screen of its own, so it renders as plain text — a null url — the way the wireframe writes it. --}} @endsection @section('content')
{{-- v12 writes the icon's two declarations inline (`style="color:var(--primary);margin-right:8px;"`, line 123). They are `.card-header-icon` here — same colour, same 8px, same variable — for the reason the inquiries module's style partial gives for its own inline conversions: an attribute repeated on every page it appears on is a rule that cannot be changed in one place. --}}
{{ __('booking_types.title') }}
@can('create', \App\Models\BookingType::class) {{-- Opened by Bootstrap's own data attributes rather than by the module's script, so the button still works if that file fails to load. The script's only job on this control is to move focus to the input once the dialog is on screen, and to empty the fields when it closes. --}} @endcan
{{-- `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 component and its test 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. --}}
{{-- yajra's own 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']) !!} @include('booking_types.partials.modals') {{-- The shared row-delete confirmation (CR-16 item J8). At the END of the content section and outside every `.card`, for the clipping reason the partial's own header records. It also pushes the toaster and the shared delete client, which is why the row buttons need nothing of their own. --}} @include('partials.ajax-delete-modal') @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. --}} @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. --}} {{-- yajra's init script — a @endpush