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

282 lines
11 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*/ -}}
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
<input type="hidden" name="{{ .PaymentSlug.Name }}" value="{{ .PaymentSlug.Val }}">
{{ if .Error -}}
<p class="error">{{ .Error }}</p>
{{- end }}
{{ with .CampsiteType -}}
<label>
{{( pgettext "Accommodation" "title" )}}<br>
<select name="{{ .Name }}"
required
data-hx-get="{{ $.URL }}" data-hx-trigger="change"
{{ template "error-attrs" . }}
“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
>
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
<option value="">{{( gettext "Choose an accommodation" )}}</option>
{{ template "list-options" . }}
</select><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .Dates -}}
<fieldset class="booking-period"
data-hx-get="{{ $.URL }}"
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 }}"
“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 }}
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
</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>
“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 }}
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
{{- end }}
{{ with $guests := .Guests -}}
{{ $draft := $.Cart.Draft }}
<fieldset class="booking-items"
data-hx-get="{{ $.URL }}" 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 -}}
“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
<tr>
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
<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>
“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
</tr>
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
{{- end }}
{{ with .NumberTeenagers -}}
“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
<tr>
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
<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>
“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
</tr>
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
{{- 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 -}}
“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
<tr>
<td>
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
<input id="{{ .Input.Name }}" type="number" required
name="{{ .Input.Name }}" value="{{ .Input.Val }}"
min="{{ .Min }}" max="{{ .Max }}"
{{ template "error-attrs" .Input }}
“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
>
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
“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
</td>
<td>
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
<label for="{{ .Input.Name }}">{{ .Label }}</label><br>
{{ template "error-message" .Input }}
“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
</td>
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
<td class="numeric">{{ formatPrice .Subtotal }}</td>
“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
</tr>
{{- end }}
{{- end }}
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
<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>
{{( pgettext "Country (optional)" "input" )}}<br>
<select name="{{ .Name }}"
{{ template "error-attrs" . }}
>
Add an empty value to the “choose country” option in booking form Otherwise, the value is the same as the label
2024-04-26 15:31:13 +00:00
<option value="">{{( gettext "Choose a country" )}}</option>
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
{{ template "list-options" . }}
</select><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .Address -}}
<label class="colspan">
{{( pgettext "Address (optional)" "input" )}}<br>
<input type="text"
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .PostalCode -}}
<label>
{{( pgettext "Postcode (optional)" "input" )}}<br>
<input type="text"
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .City -}}
<label>
{{( pgettext "Town or village (optional)" "input" )}}<br>
<input type="text"
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .Email -}}
<label>
{{( pgettext "Email (optional)" "input" )}}<br>
<input type="email"
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with .Phone -}}
<label>
{{( pgettext "Phone (optional)" "input" )}}<br>
<input type="tel"
name="{{ .Name }}" value="{{ .Val }}" {{ template "error-attrs" . }}
><br>
{{ template "error-message" . }}
</label>
{{- end }}
{{ with $.Guests.ACSICard -}}
<label class="colspan" data-hx-get="{{ $.URL }}" data-hx-trigger="change">
<input type="checkbox" name="{{ .Name }}" {{ if .Checked}}checked{{ end }}
{{ template "error-attrs" . }}
Change “ACSI” to “ACSI / ANWB” Apparently, ANWB is a camping card similar to ACSI from the Netherlands, and both cards have the exact same discounts.
2024-05-13 08:40:21 +00:00
> {{( pgettext "ACSI / ANWB card? (optional)" "input" )}}<br>
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
{{ template "error-message" . }}
</label>
{{- end }}
</fieldset>
{{- end }}
{{ if .Campsites -}}
<h3>{{( pgettext "Campsites" "title" )}}</h3>
{{ template "grid.gohtml" . }}
{{ if .Error -}}
<p class="error">{{ .Error }}</p>
“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 }}
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
{{- end }}
“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
{{ 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 }}"
Allow updating bookings I need to retrieve the values from the database and put them in the form, like all other forms, but in this case the processing is done as if it were a new form, because everything comes from the query string and there is no need to do any extra work then. Had to move the <footer> from the fields.gohtml to form.gohtml because then it could not know that it was editing an existing booking. Had to move the <fieldset> out too, in order to give it an ID and make it htmx’s target, or it would replace the form, causing even more problems —the button would disappear then—. The target **must** be in <form> because it is needed for tis children’s hx-get and for its own hx-put.
2024-04-25 18:27:08 +00:00
{{- if .Selected }} checked="checked"{{ end -}}
“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
> {{ .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 }}