tandem/camper
tandem
/
camper
2
0
Fork 0
Code Issues 7 Pull Requests Packages Projects Releases Wiki Activity
camper/pkg/booking/cart.go

257 lines
6.1 KiB
Go
Raw Normal View History

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
package booking
import (
"context"
"strconv"
"time"
"dev.tandem.ws/tandem/camper/pkg/database"
"dev.tandem.ws/tandem/camper/pkg/locale"
)
type bookingCart struct {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
Draft *paymentDraft
Show a disclaimer on top of book button that it is in fact a prebooking
2024-02-15 14:54:22 +00:00
Lines []*cartLine
Total string
DownPayment string
DownPaymentPercent int
Enabled bool
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
}
type cartLine struct {
Concept string
Units int
Subtotal string
}
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
type paymentDraft struct {
ArrivalDate time.Time
DepartureDate time.Time
NumAdults int
NumTeenagers int
NumChildren int
NumDogs int
ZonePreferences string
ACSICard bool
PaymentID int
NumNights int
Nights string
Adults string
Teenagers string
Children string
Dogs string
TouristTax string
Total string
DownPaymentPercent int
DownPayment string
Options []*paymentOption
}
type paymentOption struct {
ID int
Label string
Units int
Subtotal string
}
func draftPayment(ctx context.Context, conn *database.Conn, f *bookingForm, campsiteType string) (*paymentDraft, error) {
var err error
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.Dates == nil {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
return nil, nil
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
}
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
draft := &paymentDraft{}
draft.ArrivalDate, err = time.Parse(database.ISODateFormat, f.Dates.ArrivalDate.Val)
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
if err != nil {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
return nil, nil
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
}
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
draft.DepartureDate, err = time.Parse(database.ISODateFormat, f.Dates.DepartureDate.Val)
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
if err != nil {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
return nil, nil
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
}
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.Guests == nil {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
return nil, 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
}
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
draft.NumAdults, err = strconv.Atoi(f.Guests.NumberAdults.Val)
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
if err != nil {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
return nil, nil
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
}
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
draft.NumTeenagers, err = strconv.Atoi(f.Guests.NumberTeenagers.Val)
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
if err != nil {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
return nil, nil
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
}
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
draft.NumChildren, err = strconv.Atoi(f.Guests.NumberChildren.Val)
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
if err != nil {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
return nil, nil
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 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
if f.Guests.NumberDogs != nil {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
draft.NumDogs, err = strconv.Atoi(f.Guests.NumberDogs.Val)
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
if err != nil {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
return nil, nil
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
}
}
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
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
if f.Options != nil && f.Options.ZonePreferences != nil {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
draft.ZonePreferences = f.Options.ZonePreferences.Val
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
}
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
Compute ACSI discount After months of keeping what does the ACSI checkbox mean, now customer told us that we should add a discount based on a series of arbitrary conditions that, and need to be done NOW! There is no UI to edit the conditions due to lack of time.
2024-03-14 21:08:01 +00:00
if f.Guests.ACSICard != nil {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
draft.ACSICard = f.Guests.ACSICard.Checked
Compute ACSI discount After months of keeping what does the ACSI checkbox mean, now customer told us that we should add a discount based on a series of arbitrary conditions that, and need to be done NOW! There is no UI to edit the conditions due to lack of time.
2024-03-14 21:08:01 +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
optionMap := make(map[int]*campsiteTypeOption)
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
var typeOptions []*campsiteTypeOption
if f.Options != nil {
typeOptions = f.Options.Options
}
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
optionUnits := make([]*database.OptionUnits, 0, len(typeOptions))
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
for _, option := range typeOptions {
units, _ := strconv.Atoi(option.Input.Val)
if units < 1 {
continue
}
optionMap[option.ID] = option
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
optionUnits = append(optionUnits, &database.OptionUnits{
OptionID: option.ID,
Units: units,
})
}
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
row := conn.QueryRow(ctx, `
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
select payment.slug
, payment_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
, departure_date - arrival_date
, to_price(subtotal_nights, decimal_digits)
, to_price(subtotal_adults, decimal_digits)
, to_price(subtotal_teenagers, decimal_digits)
, to_price(subtotal_children, decimal_digits)
, to_price(subtotal_dogs, decimal_digits)
, to_price(subtotal_tourist_tax, decimal_digits)
, to_price(total, decimal_digits)
Add down payment Customer wants to require a down payment of 30 % for bookings made one week or more before the actual date, and to make the full payment otherwise. This would require yet another relation to keep these values. Fuck it; i added them to the function, as they are very unlikely to change. That forced me to change the test for draft_payment to use relative dates, otherwise there is no way i can have stable results in the future.
2024-02-13 22:45:25 +00:00
, to_price(payment.down_payment, decimal_digits)
Show a disclaimer on top of book button that it is in fact a prebooking
2024-02-15 14:54:22 +00:00
, (payment.down_payment_percent * 100)::int
Compute ACSI discount After months of keeping what does the ACSI checkbox mean, now customer told us that we should add a discount based on a series of arbitrary conditions that, and need to be done NOW! There is no UI to edit the conditions due to lack of time.
2024-03-14 21:08:01 +00:00
from draft_payment($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11) as payment
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
join currency using (currency_code)
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
`,
database.ZeroNullUUID(f.PaymentSlug.Val),
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
draft.ArrivalDate,
draft.DepartureDate,
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
campsiteType,
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
draft.NumAdults,
draft.NumTeenagers,
draft.NumChildren,
draft.NumDogs,
draft.ZonePreferences,
draft.ACSICard,
Change draft_payment return type to row of payment This way i can use the function in the from clause of the query that i already had to do to get the totals formatted with to_price. In this case, i believe it is better to leave out Go’s function because it would force me to perform two queries. Instead of binding a nullable string pointer with the payment’s slug, i wanted to use pgtype’s zeronull.Text type, but it can not work in this case because it encodes the value as a text, while the parameters is uuid. I can not use zero.UUID, because it is a [16]byte array, while i have it in a string. Thus, had to create my own ZeroNullUUID type that use a string as a base but encodes it as a UUID.
2024-02-13 18:51:39 +00:00
database.OptionUnitsArray(optionUnits),
)
Add down payment Customer wants to require a down payment of 30 % for bookings made one week or more before the actual date, and to make the full payment otherwise. This would require yet another relation to keep these values. Fuck it; i added them to the function, as they are very unlikely to change. That forced me to change the test for draft_payment to use relative dates, otherwise there is no way i can have stable results in the future.
2024-02-13 22:45:25 +00:00
if err = row.Scan(
&f.PaymentSlug.Val,
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
&draft.PaymentID,
&draft.NumNights,
&draft.Nights,
&draft.Adults,
&draft.Teenagers,
&draft.Children,
&draft.Dogs,
&draft.TouristTax,
&draft.Total,
&draft.DownPayment,
&draft.DownPaymentPercent,
Add down payment Customer wants to require a down payment of 30 % for bookings made one week or more before the actual date, and to make the full payment otherwise. This would require yet another relation to keep these values. Fuck it; i added them to the function, as they are very unlikely to change. That forced me to change the test for draft_payment to use relative dates, otherwise there is no way i can have stable results in the future.
2024-02-13 22:45:25 +00:00
); err != nil {
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
if database.ErrorIsNotFound(err) {
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
return nil, nil
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
}
return nil, err
}
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
rows, err := conn.Query(ctx, `
select campsite_type_option_id
, units
, to_price(subtotal, decimal_digits)
from payment_option
join payment using (payment_id)
join currency using (currency_code)
where payment_id = $1
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
order by campsite_type_option_id
`, draft.PaymentID)
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
if err != nil {
return nil, err
}
defer rows.Close()
for rows.Next() {
var optionID int
var units int
var subtotal string
err = rows.Scan(&optionID, &units, &subtotal)
if err != nil {
return nil, err
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 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
option := optionMap[optionID]
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
if option == nil {
continue
}
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
draft.Options = append(draft.Options, &paymentOption{
ID: option.ID,
Label: option.Label,
Units: units,
Subtotal: subtotal,
})
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
}
if rows.Err() != nil {
return nil, rows.Err()
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
}
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
return draft, nil
}
func newBookingCart(ctx context.Context, conn *database.Conn, f *bookingForm, campsiteType string) (*bookingCart, error) {
cart := &bookingCart{
Total: "0.0",
}
draft, err := draftPayment(ctx, conn, f, campsiteType)
if err != nil {
return nil, err
}
if draft == nil {
return cart, nil
}
cart.Draft = draft
cart.DownPaymentPercent = draft.DownPaymentPercent
maybeAddLine := func(units int, subtotal string, concept string) {
if units > 0 && subtotal != "" {
cart.Lines = append(cart.Lines, &cartLine{
Concept: concept,
Units: units,
Subtotal: subtotal,
})
}
}
maybeAddLine(draft.NumNights, draft.Nights, locale.PgettextNoop("Night", "cart"))
maybeAddLine(draft.NumAdults, draft.Adults, locale.PgettextNoop("Adult", "cart"))
maybeAddLine(draft.NumTeenagers, draft.Teenagers, locale.PgettextNoop("Teenager", "cart"))
maybeAddLine(draft.NumChildren, draft.Children, locale.PgettextNoop("Child", "cart"))
maybeAddLine(draft.NumDogs, draft.Dogs, locale.PgettextNoop("Dog", "cart"))
for _, option := range draft.Options {
maybeAddLine(option.Units, option.Subtotal, option.Label)
}
maybeAddLine(draft.NumAdults, draft.TouristTax, locale.PgettextNoop("Tourist tax", "cart"))
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
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
if draft.Total != "0.0" {
cart.Total = draft.Total
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
cart.Enabled = f.Guests.Error == nil
Add down payment Customer wants to require a down payment of 30 % for bookings made one week or more before the actual date, and to make the full payment otherwise. This would require yet another relation to keep these values. Fuck it; i added them to the function, as they are very unlikely to change. That forced me to change the test for draft_payment to use relative dates, otherwise there is no way i can have stable results in the future.
2024-02-13 22:45:25 +00:00
“Mockup” for the new booking form It does nothing but compute the total of a booking, much like it does for guests. In fact, i use the same payment relations to do the exact same computation, otherwise i am afraid i will make a mistake in the ACSI or such, now or in future version; better if both are exactly the same. The idea is that once the user creates the booking, i will delete that payment, because it makes no sense to keep it in this case; nobody is going to pay for it. Had to reuse the grid showing the bookings of campsites because employees need to select one or more campsites to book, and need to see which are available. In this case, i have to filter by campsite type and use the arrival and departure dates to filter the months, now up to the day, not just month. Had to change max width of th and td in the grid to take into account that now a month could have a single day, for instance, and the month heading can not stretch the day or booking spans would not be in their correct positions. For that, i needed to access campsiteEntry, bookingEntry, and Month from campsite package, but campsite imports campsite/types, and campsite/types already imports booking for the BookingDates type. To break the cycle, had to move all that to booking and use from campsite; it is mostly unchanged, except for the granularity of dates up to days instead of just months. The design of this form calls for a different way of showing the totals, because here employees have to see the amount next to the input with the units, instead of having a footer with the table. I did not like the idea of having to query the database for that, therefore i “lifter” the payment draft into a struct that both public and admin forms use to show they respective views of the cart.
2024-04-23 19:07:41 +00:00
if draft.DownPayment != draft.Total {
cart.DownPayment = draft.DownPayment
Add down payment Customer wants to require a down payment of 30 % for bookings made one week or more before the actual date, and to make the full payment otherwise. This would require yet another relation to keep these values. Fuck it; i added them to the function, as they are very unlikely to change. That forced me to change the test for draft_payment to use relative dates, otherwise there is no way i can have stable results in the future.
2024-02-13 22:45:25 +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
}
return cart, nil
}