tandem
/
camper
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
camper/web/templates/admin/booking/fields.gohtml

288 lines
12 KiB
Plaintext
Raw Normal View History

“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
<!--
SPDX-FileCopyrightText: 2023 jordi fita mas <jordi@tandem.blog>
SPDX-FileCopyrightText: 2023 Oriol Carbonell <info@oriolcarbonell.cat>
SPDX-License-Identifier: AGPL-3.0-only
-->
{{- /*gotype: dev.tandem.ws/tandem/camper/pkg/booking.adminBookingForm*/ -}}
{{ CSRFInput }}
<fieldset>
<input type="hidden" name="{{ .PaymentSlug.Name }}" value="{{ .PaymentSlug.Val }}">
{{ with .CampsiteType -}}
<label>
{{( pgettext "Accommodation" "title" )}}<br>
<select name="{{ .Name }}"
required
data-hx-get="/admin/bookings/new" data-hx-trigger="change"
{{ template "error-attrs" . }}
>
“Finish” the new booking form Had to bring the same fields that i have for a payment to booking, except that some of those should be nullable, because it is unreasonable to ask front desk to gather all customer data when they have a booking via phone, for instance. Therefore, i can not take advantage of the validation for customer data that i use in the public-facing form, but, fortunately, most of the validations where in separated functions, thus only had to rewrite that one for this case. I already have to create a booking from a payment, when receiving a payment from the public instance, thus i made that function and reused it here. Then i “overwrite” the newly created pre-booking with the customer data from the form, and set is as confirmed, as we do not see any point of allowing pre-bookings from employees.
2024-04-24 18:12:29 +00:00
<option value="">{{( gettext "Choose an accommodation" )}}</option>
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
{{ template "list-options" . }}
</select><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .Dates -}}
<fieldset class="booking-period"
data-hx-get="/admin/bookings/new"
data-hx-trigger="change delay:500ms"
>
{{ with .ArrivalDate -}}
<label>
{{( pgettext "Arrival date" "input" )}}<br>
<input type="date" required
min="{{ formatDateAttr .MinDate }}"
max="{{ formatDateAttr .MaxDate }}"
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .DepartureDate -}}
<label>
{{( pgettext "Departure date" "input" )}}<br>
<input type="date" required
min="{{ formatDateAttr .MinDate }}"
max="{{ formatDateAttr .MaxDate }}"
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
</fieldset>
{{- end }}
{{ with .Options -}}
{{ with .ZonePreferences -}}
<label>{{( pgettext "Area preferences (optional)" "input" )}}<br>
<input type="text"
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
<a href="/{{ currentLocale }}/campground?zones" target="_blank">{{( gettext "Campground map" )}}</a><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{- end }}
{{ with $guests := .Guests -}}
{{ $draft := $.Cart.Draft }}
<fieldset class="booking-items"
data-hx-get="/admin/bookings/new" data-hx-trigger="change"
>
<table>
<thead>
<tr>
<th scope="col">{{( pgettext "Units" "header" )}}</th>
<th scope="col">{{( pgettext "Decription" "header" )}}</th>
<th scope="col" class="numeric">{{( pgettext "Total" "header" )}}</th>
</tr>
</thead>
<tbody>
<tr>
<td>{{ $draft.NumNights }}</td>
<td>{{( pgettext "Night" "cart" )}}</td>
<td class="numeric">{{ formatPrice $draft.Nights }}</td>
</tr>
{{ with .NumberAdults -}}
<tr>
<td><input id="adults" type="number" required
name="{{ .Name }}" value="{{ .Val }}"
min="1"{{if not $guests.OverflowAllowed }} max="{{ $guests.MaxGuests }}"{{ end }}
{{ template "error-attrs" . }}
>
</td>
<td>
<label for="adults">{{( pgettext "Adults aged 17 or older" "input" )}}</label><br>
{{ template "error-message" . }}
</td>
<td class="numeric">{{ formatPrice $draft.Adults }}</td>
</tr>
{{- end }}
{{ with .NumberTeenagers -}}
<tr>
<td>
<input id="teenagers" type="number" required
name="{{ .Name }}" value="{{ .Val }}"
min="0"{{if not $guests.OverflowAllowed }} max="{{ $guests.MaxGuests | dec }}"{{ end }}
{{ template "error-attrs" . }}
>
</td>
<td>
<label for="teenagers">{{( pgettext "Teenagers from 11 to 16 years old" "input" )}}</label><br>
{{ template "error-message" . }}
</td>
<td class="numeric">{{ formatPrice $draft.Teenagers }}</td>
</tr>
{{- end }}
{{ with .NumberChildren -}}
<tr>
<td>
<input id="children" type="number" required
name="{{ .Name }}" value="{{ .Val }}"
min="0"{{if not $guests.OverflowAllowed }} max="{{ $guests.MaxGuests | dec }}"{{ end }}
{{ template "error-attrs" . }}
>
</td>
<td>
<label for="children">{{( pgettext "Children from 2 to 10 years old" "input" )}}</label><br>
{{ template "error-message" . }}
</td>
<td class="numeric">{{ formatPrice $draft.Children }}</td>
</tr>
{{- end }}
{{ with .NumberDogs -}}
<tr>
<td>
<input id="dogs" type="number" required
name="{{ .Name }}" value="{{ .Val }}" min="0"
{{ template "error-attrs" . }}
>
</td>
<td>
<label for="dogs">{{( pgettext "Dogs" "input" )}}</label><br>
{{ template "error-message" . }}
</td>
<td class="numeric">{{ formatPrice $draft.Dogs }}</td>
</tr>
{{- end }}
{{ with $.Options -}}
{{ range .Options -}}
<tr>
<td>
<input id="{{ .Input.Name }}" type="number" required
name="{{ .Input.Name }}" value="{{ .Input.Val }}"
min="{{ .Min }}" max="{{ .Max }}"
{{ template "error-attrs" .Input }}
>
</td>
<td>
<label for="{{ .Input.Name }}">{{ .Label }}</label><br>
{{ template "error-message" .Input }}
</td>
<td class="numeric">{{ formatPrice .Subtotal }}</td>
</tr>
{{- end }}
{{- end }}
<tr>
<td>{{ $draft.NumAdults }}</td>
<td>{{( pgettext "Tourist tax" "cart" )}}</td>
<td class="numeric">{{ formatPrice $draft.TouristTax }}</td>
</tr>
</tbody>
<tfoot>
<tr>
<th scope="row" colspan="2" class="numeric">{{( pgettext "Total" "header" )}}</th>
<td class="numeric">{{ formatPrice $draft.Total }}</td>
</tr>
</tfoot>
</table>
{{ if not .NumberDogs -}}
<small>{{( gettext "Note: This accommodation does <strong>not</strong> allow dogs.") | raw }}</small>
{{- end }}
{{ if .Error -}}
<p class="error">{{ .Error }}</p>
{{- end }}
</fieldset>
{{- end }}
{{ with .Customer -}}
<fieldset class="customer-details">
<legend>{{( pgettext "Customer Details" "title" )}}</legend>
{{ with .FullName -}}
<label>
{{( pgettext "Full name" "input" )}}<br>
<input type="text" required minlength="2"
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .Country -}}
<label>
“Finish” the new booking form Had to bring the same fields that i have for a payment to booking, except that some of those should be nullable, because it is unreasonable to ask front desk to gather all customer data when they have a booking via phone, for instance. Therefore, i can not take advantage of the validation for customer data that i use in the public-facing form, but, fortunately, most of the validations where in separated functions, thus only had to rewrite that one for this case. I already have to create a booking from a payment, when receiving a payment from the public instance, thus i made that function and reused it here. Then i “overwrite” the newly created pre-booking with the customer data from the form, and set is as confirmed, as we do not see any point of allowing pre-bookings from employees.
2024-04-24 18:12:29 +00:00
{{( pgettext "Country (optional)" "input" )}}<br>
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
<select name="{{ .Name }}"
{{ template "error-attrs" . }}
>
<option>{{( gettext "Choose a country" )}}</option>
{{ template "list-options" . }}
</select><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .Address -}}
<label class="colspan">
“Finish” the new booking form Had to bring the same fields that i have for a payment to booking, except that some of those should be nullable, because it is unreasonable to ask front desk to gather all customer data when they have a booking via phone, for instance. Therefore, i can not take advantage of the validation for customer data that i use in the public-facing form, but, fortunately, most of the validations where in separated functions, thus only had to rewrite that one for this case. I already have to create a booking from a payment, when receiving a payment from the public instance, thus i made that function and reused it here. Then i “overwrite” the newly created pre-booking with the customer data from the form, and set is as confirmed, as we do not see any point of allowing pre-bookings from employees.
2024-04-24 18:12:29 +00:00
{{( pgettext "Address (optional)" "input" )}}<br>
<input type="text"
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .PostalCode -}}
<label>
“Finish” the new booking form Had to bring the same fields that i have for a payment to booking, except that some of those should be nullable, because it is unreasonable to ask front desk to gather all customer data when they have a booking via phone, for instance. Therefore, i can not take advantage of the validation for customer data that i use in the public-facing form, but, fortunately, most of the validations where in separated functions, thus only had to rewrite that one for this case. I already have to create a booking from a payment, when receiving a payment from the public instance, thus i made that function and reused it here. Then i “overwrite” the newly created pre-booking with the customer data from the form, and set is as confirmed, as we do not see any point of allowing pre-bookings from employees.
2024-04-24 18:12:29 +00:00
{{( pgettext "Postcode (optional)" "input" )}}<br>
<input type="text"
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .City -}}
<label>
“Finish” the new booking form Had to bring the same fields that i have for a payment to booking, except that some of those should be nullable, because it is unreasonable to ask front desk to gather all customer data when they have a booking via phone, for instance. Therefore, i can not take advantage of the validation for customer data that i use in the public-facing form, but, fortunately, most of the validations where in separated functions, thus only had to rewrite that one for this case. I already have to create a booking from a payment, when receiving a payment from the public instance, thus i made that function and reused it here. Then i “overwrite” the newly created pre-booking with the customer data from the form, and set is as confirmed, as we do not see any point of allowing pre-bookings from employees.
2024-04-24 18:12:29 +00:00
{{( pgettext "Town or village (optional)" "input" )}}<br>
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
<input type="text"
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .Email -}}
<label>
“Finish” the new booking form Had to bring the same fields that i have for a payment to booking, except that some of those should be nullable, because it is unreasonable to ask front desk to gather all customer data when they have a booking via phone, for instance. Therefore, i can not take advantage of the validation for customer data that i use in the public-facing form, but, fortunately, most of the validations where in separated functions, thus only had to rewrite that one for this case. I already have to create a booking from a payment, when receiving a payment from the public instance, thus i made that function and reused it here. Then i “overwrite” the newly created pre-booking with the customer data from the form, and set is as confirmed, as we do not see any point of allowing pre-bookings from employees.
2024-04-24 18:12:29 +00:00
{{( pgettext "Email (optional)" "input" )}}<br>
<input type="email"
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .Phone -}}
<label>
“Finish” the new booking form Had to bring the same fields that i have for a payment to booking, except that some of those should be nullable, because it is unreasonable to ask front desk to gather all customer data when they have a booking via phone, for instance. Therefore, i can not take advantage of the validation for customer data that i use in the public-facing form, but, fortunately, most of the validations where in separated functions, thus only had to rewrite that one for this case. I already have to create a booking from a payment, when receiving a payment from the public instance, thus i made that function and reused it here. Then i “overwrite” the newly created pre-booking with the customer data from the form, and set is as confirmed, as we do not see any point of allowing pre-bookings from employees.
2024-04-24 18:12:29 +00:00
{{( pgettext "Phone (optional)" "input" )}}<br>
<input type="tel"
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with $.Guests.ACSICard -}}
<label class="colspan" data-hx-get="/admin/bookings/new" data-hx-trigger="change">
<input type="checkbox" name="{{ .Name }}" {{ if .Checked}}checked{{ end }}
{{ template "error-attrs" . }}
> {{( pgettext "ACSI card? (optional)" "input" )}}<br>
{{ template "error-message" . }}
</label>
{{- end }}
</fieldset>
{{- end }}
{{ if .Campsites -}}
<h3>{{( pgettext "Campsites" "title" )}}</h3>
{{ template "grid.gohtml" . }}
{{- end }}
</fieldset>
<footer>
<button type="submit">
{{- if .ID -}}
{{( pgettext "Update" "action" )}}
{{- else -}}
{{( pgettext "Add" "action" )}}
{{- end -}}
</button>
</footer>
{{ define "campsite-heading" -}}
“Finish” the new booking form Had to bring the same fields that i have for a payment to booking, except that some of those should be nullable, because it is unreasonable to ask front desk to gather all customer data when they have a booking via phone, for instance. Therefore, i can not take advantage of the validation for customer data that i use in the public-facing form, but, fortunately, most of the validations where in separated functions, thus only had to rewrite that one for this case. I already have to create a booking from a payment, when receiving a payment from the public instance, thus i made that function and reused it here. Then i “overwrite” the newly created pre-booking with the customer data from the form, and set is as confirmed, as we do not see any point of allowing pre-bookings from employees.
2024-04-24 18:12:29 +00:00
{{- /*gotype: dev.tandem.ws/tandem/camper/pkg/booking.CampsiteEntry*/ -}}
<label>
<input type="checkbox"
name="campsite"
value="{{ .ID }}"
{{- if .Selected }} checked="checked"{{ end -}}
> {{ .Label }}</label>
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
{{- end }}