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

60 lines
1.9 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-License-Identifier: AGPL-3.0-only
-->
{{ define "title" -}}
{{- /*gotype: dev.tandem.ws/tandem/camper/pkg/booking.adminBookingForm*/ -}}
{{ if .ID }}
{{( pgettext "Edit Booking" "title" )}}
{{ else }}
{{( pgettext "New Booking" "title" )}}
{{ 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
{{ define "head" -}}
<script src="/static/idiomorph-ext@0.3.0.min.js"></script>
{{- 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 "breadcrumb" -}}
Add the section of prebookings It is just the index of bookings in the created state, but we thought it would make easier to understand the difference between a booking from a customer not yet confirmed, from a booking confirmed or created by the staff.
2024-05-02 23:01:01 +00:00
{{ if eq .Status "created" -}}
<li><a href="/admin/prebookings">{{( pgettext "Prebookings" "title" )}}</a></li>
{{- else -}}
<li><a href="./">{{( pgettext "Bookings" "title" )}}</a></li>
{{- 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
{{- end }}
{{ define "content" -}}
{{- /*gotype: dev.tandem.ws/tandem/camper/pkg/booking.adminBookingForm*/ -}}
Add check-in form I based the form from the documentation given by the Mossos d’Esquadra[0], required by law. https://registreviatgers.mossos.gencat.cat/mossos_hotels/AppJava/fitxaviatger.do?reqCode=create
2024-04-26 15:09:36 +00:00
{{ if .ID -}}
Add the section of prebookings It is just the index of bookings in the created state, but we thought it would make easier to understand the difference between a booking from a customer not yet confirmed, from a booking confirmed or created by the staff.
2024-05-02 23:01:01 +00:00
{{ if ne .Status "created" -}}
<a href="{{ .URL }}/check-in">{{( pgettext "Check-in Booking" "action" )}}</a>
<a href="/admin/invoices/new?booking={{ .ID }}">{{( pgettext "Invoice Booking" "action" )}}</a>
{{- end }}
Add invoicing of bookings It is a bit user-hostile because you have to create a new customer prior to create the invoice, but that’s what it is for now.
2024-04-28 19:56:51 +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
<h2>{{ template "title" .}}</h2>
<form id="booking-form"
data-hx-ext="morph"
data-hx-swap="morph:innerHTML"
data-hx-include="this"
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
data-hx-target="#booking-form-fields"
“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
data-hx-replace-url="true"
Fix null problems
2024-04-28 20:49:04 +00:00
{{- if .ID }} data-hx-put="{{ .URL }}"
“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
{{- else }} action="/admin/bookings" method="post"
{{- 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
{{ CSRFInput }}
<fieldset id="booking-form-fields">
{{ template "fields.gohtml" . }}
</fieldset>
<footer>
<button type="submit">
{{- if .ID -}}
{{( pgettext "Update" "action" )}}
{{- else -}}
{{( pgettext "Add" "action" )}}
{{- end -}}
</button>
</footer>
“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
</form>
{{- end }}