Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
/ *
* SPDX - FileCopyrightText : 2023 jordi fita mas < jfita @ peritasoft . com >
* SPDX - License - Identifier : AGPL - 3.0 - only
* /
package booking
import (
"context"
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
"errors"
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
"fmt"
"net/http"
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
"strconv"
"time"
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
"dev.tandem.ws/tandem/camper/pkg/auth"
"dev.tandem.ws/tandem/camper/pkg/database"
"dev.tandem.ws/tandem/camper/pkg/form"
httplib "dev.tandem.ws/tandem/camper/pkg/http"
"dev.tandem.ws/tandem/camper/pkg/locale"
"dev.tandem.ws/tandem/camper/pkg/template"
)
type PublicHandler struct {
}
func NewPublicHandler ( ) * PublicHandler {
return & PublicHandler { }
}
func ( h * PublicHandler ) Handler ( user * auth . User , company * auth . Company , conn * database . Conn ) http . Handler {
return http . HandlerFunc ( func ( w http . ResponseWriter , r * http . Request ) {
var head string
head , r . URL . Path = httplib . ShiftPath ( r . URL . Path )
switch head {
case "" :
switch r . Method {
case http . MethodGet :
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
page , err := newPublicPage ( r , company , conn , user . Locale )
if err != nil {
http . Error ( w , err . Error ( ) , http . StatusBadRequest )
return
}
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
page . MustRender ( w , r , user , company , conn )
case http . MethodPost :
2024-02-12 17:06:17 +00:00
requestPayment ( w , r , user , company , conn )
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
default :
httplib . MethodNotAllowed ( w , r , http . MethodGet , http . MethodPost )
}
default :
http . NotFound ( w , r )
}
} )
}
type publicPage struct {
* template . PublicPage
Form * bookingForm
}
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
func newPublicPage ( r * http . Request , company * auth . Company , conn * database . Conn , l * locale . Locale ) ( * publicPage , error ) {
f , err := newBookingForm ( r , company , conn , l )
if err != nil {
return nil , err
}
return newPublicPageWithForm ( f ) , nil
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
}
func newPublicPageWithForm ( form * bookingForm ) * publicPage {
return & publicPage {
PublicPage : template . NewPublicPage ( ) ,
Form : form ,
}
}
func ( p * publicPage ) MustRender ( w http . ResponseWriter , r * http . Request , user * auth . User , company * auth . Company , conn * database . Conn ) {
p . Setup ( r , user , company , conn )
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
var err error
if err != nil {
panic ( err )
}
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
if httplib . IsHTMxRequest ( r ) {
template . MustRenderPublicNoLayout ( w , r , user , company , "booking/fields.gohtml" , p )
} else {
template . MustRenderPublicFiles ( w , r , user , company , p , "booking/page.gohtml" , "booking/fields.gohtml" )
}
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
}
type bookingForm struct {
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
CampsiteType * form . Select
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
PaymentSlug * form . Input
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
Dates * DateFields
Guests * bookingGuestFields
Options * bookingOptionFields
Customer * bookingCustomerFields
Cart * bookingCart
}
type DateFields struct {
MinNights int
MaxNights int
ArrivalDate * bookingDateInput
DepartureDate * bookingDateInput
}
type bookingDateInput struct {
* form . Input
MinDate time . Time
MaxDate time . Time
}
type bookingGuestFields struct {
MaxGuests int
OverflowAllowed bool
2024-02-11 21:06:00 +00:00
Overflow bool
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
NumberAdults * form . Input
NumberTeenagers * form . Input
NumberChildren * form . Input
NumberDogs * form . Input
Error error
}
type bookingOptionFields struct {
Legend string
ZonePreferences * form . Input
Options [ ] * campsiteTypeOption
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
}
type campsiteTypeOption struct {
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
ID int
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
Label string
Min int
Max int
Input * form . Input
}
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
type bookingCustomerFields struct {
FullName * form . Input
Address * form . Input
PostalCode * form . Input
City * form . Input
Country * form . Select
Email * form . Input
Phone * form . Input
ACSICard * form . Checkbox
Agreement * form . Checkbox
}
func newBookingForm ( r * http . Request , company * auth . Company , conn * database . Conn , l * locale . Locale ) ( * bookingForm , error ) {
if err := r . ParseForm ( ) ; err != nil {
return nil , err
}
f := & bookingForm {
CampsiteType : & form . Select {
Name : "campsite_type" ,
Options : form . MustGetOptions ( r . Context ( ) , conn , "select type.slug, coalesce(i18n.name, type.name) as l10n_name from campsite_type as type left join campsite_type_i18n as i18n on type.campsite_type_id = i18n.campsite_type_id and i18n.lang_tag = $1 where company_id = $2 and active order by position, l10n_name" , l . Language , company . ID ) ,
} ,
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
PaymentSlug : & form . Input {
Name : "payment_slug" ,
} ,
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
}
f . CampsiteType . FillValue ( r )
Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance. There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.
To compute the total for that payment i had to do the same as was doing
until now for the cart. To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.
Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values. Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation. It still allows payment without customer, but at least there
are no NULL values.
Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.
To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug. A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 04:21:00 +00:00
f . PaymentSlug . FillValue ( r )
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
campsiteType := f . CampsiteType . String ( )
if campsiteType == "" {
return f , nil
}
if ! f . CampsiteType . ValidOptionsSelected ( ) {
f . CampsiteType . Error = errors . New ( l . Gettext ( "Selected campsite type is not valid." ) )
return f , nil
}
var err error
f . Dates , err = NewDateFields ( r . Context ( ) , conn , campsiteType )
if err != nil {
return nil , err
}
f . Dates . FillValues ( r , l )
if f . Dates . ArrivalDate . Val == "" || f . Dates . ArrivalDate . Error != nil || f . Dates . DepartureDate . Val == "" || f . Dates . DepartureDate . Error != nil {
return f , nil
}
f . Guests , err = newBookingGuestFields ( r . Context ( ) , conn , campsiteType )
if err != nil {
return nil , err
}
f . Guests . FillValues ( r , l )
f . Options , err = newBookingOptionFields ( r . Context ( ) , conn , campsiteType , l )
if err != nil {
return nil , err
}
if f . Options != nil {
f . Options . FillValues ( r )
}
f . Customer = newBookingCustomerFields ( r . Context ( ) , conn , l )
f . Customer . FillValues ( r )
f . Cart , err = newBookingCart ( r . Context ( ) , conn , f , campsiteType )
if err != nil {
return nil , err
}
return f , nil
}
func ( f * bookingForm ) Valid ( ctx context . Context , conn * database . Conn , l * locale . Locale ) ( bool , error ) {
v := form . NewValidator ( l )
if f . Dates == nil {
return false , errors . New ( "no booking date fields" )
}
if f . Guests == nil {
return false , errors . New ( "no guests fields" )
}
if f . Customer == nil {
return false , errors . New ( "no customer fields" )
}
2024-02-12 17:06:17 +00:00
if f . Cart == nil {
return false , errors . New ( "no booking cart" )
}
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
v . CheckSelectedOptions ( f . CampsiteType , l . GettextNoop ( "Selected campsite type is not valid." ) )
f . Dates . Valid ( v , l )
f . Guests . Valid ( v , l )
2024-02-13 16:05:19 +00:00
if err := f . Customer . Valid ( ctx , conn , v , l ) ; err != nil {
return false , err
}
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
if f . Options != nil {
2024-02-13 16:05:19 +00:00
f . Options . Valid ( v , l )
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
}
return v . AllOK , nil
}
func NewDateFields ( ctx context . Context , conn * database . Conn , campsiteType string ) ( * DateFields , error ) {
row := conn . QueryRow ( ctx , `
select lower ( bookable_nights ) ,
upper ( bookable_nights ) - 1 ,
greatest ( min ( lower ( season_range ) ) , current_timestamp : : date ) ,
max ( upper ( season_range ) )
from campsite_type
join campsite_type_cost using ( campsite_type_id )
join season_calendar using ( season_id )
where campsite_type . slug = $ 1
and season_range >> daterange ( date_trunc ( ' year ' , current_timestamp ) : : date , date_trunc ( ' year ' , current_timestamp ) : : date + 1 )
group by bookable_nights ;
` , campsiteType )
f := & DateFields {
ArrivalDate : & bookingDateInput {
Input : & form . Input { Name : "arrival_date" } ,
} ,
DepartureDate : & bookingDateInput {
Input : & form . Input { Name : "departure_date" } ,
} ,
}
if err := row . Scan ( & f . MinNights , & f . MaxNights , & f . ArrivalDate . MinDate , & f . DepartureDate . MaxDate ) ; err != nil {
return nil , err
}
f . ArrivalDate . MaxDate = f . DepartureDate . MaxDate . AddDate ( 0 , 0 , - f . MinNights )
f . DepartureDate . MinDate = f . ArrivalDate . MinDate . AddDate ( 0 , 0 , f . MinNights )
return f , nil
}
func ( f * DateFields ) FillValues ( r * http . Request , l * locale . Locale ) {
f . ArrivalDate . FillValue ( r )
f . DepartureDate . FillValue ( r )
if f . ArrivalDate . Val != "" {
arrivalDate , err := time . Parse ( database . ISODateFormat , f . ArrivalDate . Val )
if err != nil {
f . ArrivalDate . Error = errors . New ( l . Gettext ( "Arrival date must be a valid date." ) )
return
}
f . DepartureDate . MinDate = arrivalDate . AddDate ( 0 , 0 , f . MinNights )
maxDate := arrivalDate . AddDate ( 0 , 0 , f . MaxNights )
if maxDate . Before ( f . DepartureDate . MaxDate ) {
f . DepartureDate . MaxDate = maxDate
}
if f . DepartureDate . Val == "" {
f . DepartureDate . Val = f . DepartureDate . MinDate . Format ( database . ISODateFormat )
} else {
departureDate , err := time . Parse ( database . ISODateFormat , f . DepartureDate . Val )
if err != nil {
f . DepartureDate . Error = errors . New ( l . Gettext ( "Departure date must be a valid date." ) )
return
}
if departureDate . Before ( f . DepartureDate . MinDate ) {
f . DepartureDate . Val = f . DepartureDate . MinDate . Format ( database . ISODateFormat )
} else if departureDate . After ( f . DepartureDate . MaxDate ) {
f . DepartureDate . Val = f . DepartureDate . MaxDate . Format ( database . ISODateFormat )
}
}
}
}
func ( f * DateFields ) Valid ( v * form . Validator , l * locale . Locale ) {
var validBefore bool
if v . CheckRequired ( f . ArrivalDate . Input , l . GettextNoop ( "Arrival date can not be empty" ) ) {
if v . CheckValidDate ( f . ArrivalDate . Input , l . GettextNoop ( "Arrival date must be a valid date." ) ) {
if v . CheckMinDate ( f . ArrivalDate . Input , f . ArrivalDate . MinDate , fmt . Sprintf ( l . Gettext ( "Arrival date must be %s or after." ) , f . ArrivalDate . MinDate . Format ( database . ISODateFormat ) ) ) {
v . CheckMaxDate ( f . ArrivalDate . Input , f . ArrivalDate . MaxDate , fmt . Sprintf ( l . Gettext ( "Arrival date must be %s or before." ) , f . ArrivalDate . MaxDate . Format ( database . ISODateFormat ) ) )
}
}
}
if v . CheckRequired ( f . DepartureDate . Input , l . GettextNoop ( "Departure date can not be empty" ) ) {
if v . CheckValidDate ( f . DepartureDate . Input , l . GettextNoop ( "Departure date must be a valid date." ) ) && validBefore {
if v . CheckMinDate ( f . DepartureDate . Input , f . DepartureDate . MinDate , fmt . Sprintf ( l . Gettext ( "Departure date must be %s or after." ) , f . DepartureDate . MinDate . Format ( database . ISODateFormat ) ) ) {
v . CheckMaxDate ( f . DepartureDate . Input , f . DepartureDate . MaxDate , fmt . Sprintf ( l . Gettext ( "Departure date must be %s or before." ) , f . DepartureDate . MaxDate . Format ( database . ISODateFormat ) ) )
}
}
}
}
func newBookingGuestFields ( ctx context . Context , conn * database . Conn , campsiteType string ) ( * bookingGuestFields , error ) {
f := & bookingGuestFields {
NumberAdults : & form . Input { Name : "number_adults" } ,
NumberTeenagers : & form . Input { Name : "number_teenagers" } ,
NumberChildren : & form . Input { Name : "number_children" } ,
}
row := conn . QueryRow ( ctx , `
select max_campers
, overflow_allowed
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
, pet . cost_per_night is not null as dogs_allowed
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
from campsite_type
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
left join campsite_type_pet_cost as pet using ( campsite_type_id )
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
where slug = $ 1
` , campsiteType )
var dogsAllowed bool
if err := row . Scan ( & f . MaxGuests , & f . OverflowAllowed , & dogsAllowed ) ; err != nil {
return nil , err
}
if dogsAllowed {
f . NumberDogs = & form . Input { Name : "number_dogs" }
}
return f , nil
}
func ( f * bookingGuestFields ) FillValues ( r * http . Request , l * locale . Locale ) {
numGuests := 0
numGuests += fillNumericField ( f . NumberAdults , r , 1 )
numGuests += fillNumericField ( f . NumberTeenagers , r , 0 )
numGuests += fillNumericField ( f . NumberChildren , r , 0 )
if f . NumberDogs != nil {
fillNumericField ( f . NumberDogs , r , 0 )
}
2024-02-11 21:06:00 +00:00
if numGuests > f . MaxGuests {
if f . OverflowAllowed {
f . Overflow = true
} else {
f . Error = fmt . Errorf ( l . Gettext ( "There can be at most %d guests in this accommodation." ) , f . MaxGuests )
}
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
}
}
func fillNumericField ( input * form . Input , r * http . Request , min int ) int {
input . FillValue ( r )
if input . Val == "" {
input . Val = strconv . Itoa ( min )
return min
}
val , err := strconv . Atoi ( input . Val )
if err != nil {
input . Val = strconv . Itoa ( min )
val = min
}
return val
}
func ( f * bookingGuestFields ) Valid ( v * form . Validator , l * locale . Locale ) {
if v . CheckRequired ( f . NumberAdults , l . GettextNoop ( "Number of adults can not be empty" ) ) {
if v . CheckValidInteger ( f . NumberAdults , l . GettextNoop ( "Number of adults must be an integer." ) ) {
v . CheckMinInteger ( f . NumberAdults , 1 , l . GettextNoop ( "There must be at least one adult." ) )
}
}
if v . CheckRequired ( f . NumberTeenagers , l . GettextNoop ( "Number of teenagers can not be empty" ) ) {
if v . CheckValidInteger ( f . NumberTeenagers , l . GettextNoop ( "Number of teenagers must be an integer." ) ) {
v . CheckMinInteger ( f . NumberTeenagers , 0 , l . GettextNoop ( "Number of teenagers can not be negative." ) )
}
}
if v . CheckRequired ( f . NumberChildren , l . GettextNoop ( "Number of children can not be empty" ) ) {
if v . CheckValidInteger ( f . NumberChildren , l . GettextNoop ( "Number of children must be an integer." ) ) {
v . CheckMinInteger ( f . NumberChildren , 0 , l . GettextNoop ( "Number of children can not be negative." ) )
}
}
2024-02-13 16:05:19 +00:00
if f . NumberDogs != nil && v . CheckRequired ( f . NumberDogs , l . GettextNoop ( "Number of dogs can not be empty" ) ) {
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
if v . CheckValidInteger ( f . NumberDogs , l . GettextNoop ( "Number of dogs must be an integer." ) ) {
v . CheckMinInteger ( f . NumberDogs , 0 , l . GettextNoop ( "Number of dogs can not be negative." ) )
}
}
}
func newBookingOptionFields ( ctx context . Context , conn * database . Conn , campsiteType string , l * locale . Locale ) ( * bookingOptionFields , error ) {
f := & bookingOptionFields { }
row := conn . QueryRow ( ctx , `
select coalesce ( i18n . name , campsite_type . name )
2024-01-29 02:38:11 +00:00
, ask_zone_preferences
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
from campsite_type
left join campsite_type_i18n as i18n on i18n . campsite_type_id = campsite_type . campsite_type_id and i18n . lang_tag = $ 1
where slug = $ 2
` , l . Language , campsiteType )
var askZonePreferences bool
if err := row . Scan ( & f . Legend , & askZonePreferences ) ; err != nil {
return nil , err
}
if askZonePreferences {
f . ZonePreferences = & form . Input { Name : "zone_preferences" }
}
rows , err := conn . Query ( ctx , `
select option . campsite_type_option_id
, ' campsite_type_option_ ' || option . campsite_type_option_id
, coalesce ( i18n . name , option . name ) as l10_name
, lower ( range ) : : text
, lower ( range )
, upper ( range )
from campsite_type_option as option
join campsite_type using ( campsite_type_id )
left join campsite_type_option_i18n as i18n on i18n . campsite_type_option_id = option . campsite_type_option_id and i18n . lang_tag = $ 1
where slug = $ 2
and campsite_type . active
order by option . position , l10_name
` , l . Language , campsiteType )
2024-01-29 02:38:11 +00:00
if err != nil {
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
return nil , err
2024-01-29 02:38:11 +00:00
}
defer rows . Close ( )
for rows . Next ( ) {
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
option := & campsiteTypeOption {
Input : & form . Input { } ,
2024-01-29 02:38:11 +00:00
}
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
if err = rows . Scan ( & option . ID , & option . Input . Name , & option . Label , & option . Input . Val , & option . Min , & option . Max ) ; err != nil {
return nil , err
2024-01-29 02:38:11 +00:00
}
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
f . Options = append ( f . Options , option )
2024-01-29 02:38:11 +00:00
}
if rows . Err ( ) != nil {
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
return nil , rows . Err ( )
}
if f . ZonePreferences == nil && len ( f . Options ) == 0 {
return nil , nil
2024-01-29 02:38:11 +00:00
}
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
return f , nil
}
func ( f * bookingOptionFields ) FillValues ( r * http . Request ) {
if f . ZonePreferences != nil {
f . ZonePreferences . FillValue ( r )
}
for _ , option := range f . Options {
fillNumericField ( option . Input , r , option . Min )
}
}
2024-01-29 02:38:11 +00:00
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
func ( f * bookingOptionFields ) Valid ( v * form . Validator , l * locale . Locale ) {
for _ , option := range f . Options {
if v . CheckRequired ( option . Input , fmt . Sprintf ( l . Gettext ( "%s can not be empty" ) , option . Label ) ) {
if v . CheckValidInteger ( option . Input , fmt . Sprintf ( l . Gettext ( "%s must be an integer." ) , option . Label ) ) {
if v . CheckMinInteger ( option . Input , option . Min , fmt . Sprintf ( l . Gettext ( "%s must be %d or greater." ) , option . Label , option . Min ) ) {
v . CheckMaxInteger ( option . Input , option . Max , fmt . Sprintf ( l . Gettext ( "%s must be at most %d." ) , option . Label , option . Max ) )
}
}
}
}
}
func newBookingCustomerFields ( ctx context . Context , conn * database . Conn , l * locale . Locale ) * bookingCustomerFields {
return & bookingCustomerFields {
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
FullName : & form . Input {
Name : "full_name" ,
} ,
Address : & form . Input {
Name : "address" ,
} ,
PostalCode : & form . Input {
Name : "postal_code" ,
} ,
City : & form . Input {
Name : "city" ,
} ,
Country : & form . Select {
Name : "country" ,
Options : form . MustGetOptions ( ctx , conn , "select country.country_code, coalesce(i18n.name, country.name) as l10n_name from country left join country_i18n as i18n on country.country_code = i18n.country_code and i18n.lang_tag = $1 order by l10n_name" , l . Language ) ,
} ,
Email : & form . Input {
Name : "email" ,
} ,
Phone : & form . Input {
Name : "phone" ,
} ,
ACSICard : & form . Checkbox {
Name : "acsi_card" ,
} ,
Agreement : & form . Checkbox {
Name : "agreement" ,
} ,
}
2024-01-29 02:38:11 +00:00
}
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
func ( f * bookingCustomerFields ) FillValues ( r * http . Request ) {
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
f . FullName . FillValue ( r )
f . Address . FillValue ( r )
f . PostalCode . FillValue ( r )
f . City . FillValue ( r )
f . Country . FillValue ( r )
f . Email . FillValue ( r )
f . Phone . FillValue ( r )
f . ACSICard . FillValue ( r )
f . Agreement . FillValue ( r )
}
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
func ( f * bookingCustomerFields ) Valid ( ctx context . Context , conn * database . Conn , v * form . Validator , l * locale . Locale ) error {
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
var country string
if v . CheckSelectedOptions ( f . Country , l . GettextNoop ( "Selected country is not valid." ) ) {
country = f . Country . Selected [ 0 ]
}
if v . CheckRequired ( f . FullName , l . GettextNoop ( "Full name can not be empty." ) ) {
v . CheckMinLength ( f . FullName , 1 , l . GettextNoop ( "Full name must have at least one letter." ) )
}
2023-12-13 22:41:47 +00:00
if country != "" && f . PostalCode . Val != "" {
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
if _ , err := v . CheckValidPostalCode ( ctx , conn , f . PostalCode , country , l . GettextNoop ( "This postal code is not valid." ) ) ; err != nil {
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
return err
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
}
}
if v . CheckRequired ( f . Email , l . GettextNoop ( "Email can not be empty." ) ) {
v . CheckValidEmail ( f . Email , l . GettextNoop ( "This email is not valid. It should be like name@domain.com." ) )
}
if v . CheckRequired ( f . Phone , l . GettextNoop ( "Phone can not be empty." ) ) {
if _ , err := v . CheckValidPhone ( ctx , conn , f . Phone , country , l . GettextNoop ( "This phone number is not valid." ) ) ; err != nil {
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
return err
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
}
}
Compute and show the “cart” for the booking form
I have to ask number and age ranges of hosts of guests for all campsite
types, not only those that have price options for adults, children, etc.
because i must compute the tourist tax for adults. These numbers will
be used to generate de rows for guests when actually creating the
booking, which is not done already.
To satisfy the campsite types that do have a price per guest, not only
per night, i had to add the prices for each range in the
campsite_type_cost relation. If a campsite type does not have price
per person, then that should be zero; the website then does not display
the price.
The minimal price for any campsite type is one adult for one night,
thus to compute the price i need at least the campsite type, the dates,
and the number of adults, that has a minimum of one. I changed the
order of the form to ask for these values first, so i can compute the
initial price as soon as possible. To help further, i show the
<fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
v . Check ( f . Agreement , f . Agreement . Checked , l . GettextNoop ( "It is mandatory to agree to the reservation conditions." ) )
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
return nil
Add the first draft of the booking and payment forms
The form is based on the one in the current website, but in a single
page instead of split into many pages; possibly each <fieldset> should
be in a separate page/view. The idea is for Oriol to check the design
and decide how it would be presented to the user, so i needed something
to show him first.
I hardcoded the **test** data for the customer’s Redsys account. Is
this bad? I hope not, but i am not really, really sure.
The data sent to Redsys is just a placeholder because there are booking
details that i do not know, like what i have to do with the “teenagers”
field or the area preferences, thus i can not yet have a booking
relation. Nevertheless, had to generate a random order number up to
12-chars in length or Redsys would refuse the payment, claiming that
the order is duplicated.
The Redsys package is based on the PHP code provided by Redsys
themselves, plus some hints at the implementations from various Go
packages that did not know why they were so complicated.
Had to grant select on table country to guest in order to show the
select with the country options.
I have changed the “Postal code” input in taxDetails for “Postcode”
because this is the spell that it is used in the current web, i did not
see a reason to change it—it is an accepted form—, and i did not want to
have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
}