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

37 lines
1.3 KiB
Plaintext
Raw Normal View History

Handle the booking cart entirely with HTMx Besides the dynamic final cart, that was already handled by HTMx, i had to check the maximum number of guests, whether the accommodation allows “overflow”, whether dogs are allowed, and that the booking dates were within the campground’s opening and closing dates. I could do all of this with AlpineJS, but then i would have to add the same validation to the backend, prior to accept the payment. Would not make more sense to have them in a single place, namely the backend? With HTMx i can do that. However, i now have to create the form “piecemeal”, because i may not have the whole information when the visitor arrives to the booking page, and i still had the same problem as in commit d2858302efa—parsing the whole form as is would leave guests and options field empty, rather than at their minimum values. One of the fieldsets in that booking form are the arrival and departure dates, that are the sames we use in the campsite type’s page to “preselect” these values. Since now are in a separate struct, i can reuse the same type and validation logic for both pages, making my JavaScript code useless, but requiring HTMx. I think this is a good tradeoff, in fact.
2024-02-10 02:49:44 +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
-->
{{ define "title" -}}
{{( pgettext "Booking" "title" )}}
{{- end }}
Use idiomorph and a delay in the booking form This is specially for the departure date: Firefox triggers a change each time the user writes something, but since the date may be outside the allowed range while the user is typing, the form replaces the input with the “corrected” one. The idiomorph thing is to keep the focus in the “same” field, from the point of view of the user. It still happens if one is slow enough, but i guess people that want to write instead of picking the date are usually fast typist. Let’s hope.
2024-02-27 19:04:04 +00:00
{{ define "head" -}}
<script src="/static/idiomorph-ext@0.3.0.min.js"></script>
{{- end }}
Handle the booking cart entirely with HTMx Besides the dynamic final cart, that was already handled by HTMx, i had to check the maximum number of guests, whether the accommodation allows “overflow”, whether dogs are allowed, and that the booking dates were within the campground’s opening and closing dates. I could do all of this with AlpineJS, but then i would have to add the same validation to the backend, prior to accept the payment. Would not make more sense to have them in a single place, namely the backend? With HTMx i can do that. However, i now have to create the form “piecemeal”, because i may not have the whole information when the visitor arrives to the booking page, and i still had the same problem as in commit d2858302efa—parsing the whole form as is would leave guests and options field empty, rather than at their minimum values. One of the fieldsets in that booking form are the arrival and departure dates, that are the sames we use in the campsite type’s page to “preselect” these values. Since now are in a separate struct, i can reuse the same type and validation logic for both pages, making my JavaScript code useless, but requiring HTMx. I think this is a good tradeoff, in fact.
2024-02-10 02:49:44 +00:00
{{ define "content" -}}
{{- /*gotype: dev.tandem.ws/tandem/camper/pkg/booking.publicPage*/ -}}
<h2>{{ template "title" . }}</h2>
Make address, postcode, and city require for booking Customer changed their mind.
2024-02-24 19:03:11 +00:00
{{ if .HasErrors -}}
<div role="alert" class="error">
<p>{{( gettext "Sorry, there was a problem. You’ll find more details highlighted below." )}}</p>
</div>
{{- end }}
Add a warning on the booking page when payment is using test environment Apparently, the bank has to validate the fucking thing on the actual domain, because of reasons, so we have to replace the current web in production with this version in test mode, meaning that users **will** believe they have paid, when in fact they have not. The warning is for these few people that actually read such notices.
2024-02-26 15:00:29 +00:00
{{ if eq .Environment "test" }}
<div role="alert" class="warning">
<p>{{( gettext "Payment is in test mode. You can make the booking regardless, but no money will be charged. We will send you an additional email with instructions on how to perform the payment." )}}</p>
</div>
{{- end }}
Handle the booking cart entirely with HTMx Besides the dynamic final cart, that was already handled by HTMx, i had to check the maximum number of guests, whether the accommodation allows “overflow”, whether dogs are allowed, and that the booking dates were within the campground’s opening and closing dates. I could do all of this with AlpineJS, but then i would have to add the same validation to the backend, prior to accept the payment. Would not make more sense to have them in a single place, namely the backend? With HTMx i can do that. However, i now have to create the form “piecemeal”, because i may not have the whole information when the visitor arrives to the booking page, and i still had the same problem as in commit d2858302efa—parsing the whole form as is would leave guests and options field empty, rather than at their minimum values. One of the fieldsets in that booking form are the arrival and departure dates, that are the sames we use in the campsite type’s page to “preselect” these values. Since now are in a separate struct, i can reuse the same type and validation logic for both pages, making my JavaScript code useless, but requiring HTMx. I think this is a good tradeoff, in fact.
2024-02-10 02:49:44 +00:00
<form id="booking" action="/{{ currentLocale }}/booking" method="post"
Use idiomorph and a delay in the booking form This is specially for the departure date: Firefox triggers a change each time the user writes something, but since the date may be outside the allowed range while the user is typing, the form replaces the input with the “corrected” one. The idiomorph thing is to keep the focus in the “same” field, from the point of view of the user. It still happens if one is slow enough, but i guess people that want to write instead of picking the date are usually fast typist. Let’s hope.
2024-02-27 19:04:04 +00:00
data-hx-ext="morph"
data-hx-swap="morph:innerHTML"
Handle the booking cart entirely with HTMx Besides the dynamic final cart, that was already handled by HTMx, i had to check the maximum number of guests, whether the accommodation allows “overflow”, whether dogs are allowed, and that the booking dates were within the campground’s opening and closing dates. I could do all of this with AlpineJS, but then i would have to add the same validation to the backend, prior to accept the payment. Would not make more sense to have them in a single place, namely the backend? With HTMx i can do that. However, i now have to create the form “piecemeal”, because i may not have the whole information when the visitor arrives to the booking page, and i still had the same problem as in commit d2858302efa—parsing the whole form as is would leave guests and options field empty, rather than at their minimum values. One of the fieldsets in that booking form are the arrival and departure dates, that are the sames we use in the campsite type’s page to “preselect” these values. Since now are in a separate struct, i can reuse the same type and validation logic for both pages, making my JavaScript code useless, but requiring HTMx. I think this is a good tradeoff, in fact.
2024-02-10 02:49:44 +00:00
data-hx-include="this"
data-hx-target="this"
data-hx-replace-url="true"
>
{{ template "fields.gohtml" . }}
</form>
{{- end }}