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

190 lines
5.8 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"
"github.com/jackc/pgx/v4"
"dev.tandem.ws/tandem/camper/pkg/database"
"dev.tandem.ws/tandem/camper/pkg/locale"
)
type bookingCart struct {
Handle the booking cart entirely with HTMx Besides the dynamic final cart, that was already handled by HTMx, i had to check the maximum number of guests, whether the accommodation allows “overflow”, whether dogs are allowed, and that the booking dates were within the campground’s opening and closing dates. I could do all of this with AlpineJS, but then i would have to add the same validation to the backend, prior to accept the payment. Would not make more sense to have them in a single place, namely the backend? With HTMx i can do that. However, i now have to create the form “piecemeal”, because i may not have the whole information when the visitor arrives to the booking page, and i still had the same problem as in commit d2858302efa—parsing the whole form as is would leave guests and options field empty, rather than at their minimum values. One of the fieldsets in that booking form are the arrival and departure dates, that are the sames we use in the campsite type’s page to “preselect” these values. Since now are in a separate struct, i can reuse the same type and validation logic for both pages, making my JavaScript code useless, but requiring HTMx. I think this is a good tradeoff, in fact.
2024-02-10 02:49:44 +00:00
Lines []*cartLine
Total string
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
}
Handle the booking cart entirely with HTMx Besides the dynamic final cart, that was already handled by HTMx, i had to check the maximum number of guests, whether the accommodation allows “overflow”, whether dogs are allowed, and that the booking dates were within the campground’s opening and closing dates. I could do all of this with AlpineJS, but then i would have to add the same validation to the backend, prior to accept the payment. Would not make more sense to have them in a single place, namely the backend? With HTMx i can do that. However, i now have to create the form “piecemeal”, because i may not have the whole information when the visitor arrives to the booking page, and i still had the same problem as in commit d2858302efa—parsing the whole form as is would leave guests and options field empty, rather than at their minimum values. One of the fieldsets in that booking form are the arrival and departure dates, that are the sames we use in the campsite type’s page to “preselect” these values. Since now are in a separate struct, i can reuse the same type and validation logic for both pages, making my JavaScript code useless, but requiring HTMx. I think this is a good tradeoff, in fact.
2024-02-10 02:49:44 +00:00
func newBookingCart(ctx context.Context, conn *database.Conn, f *bookingForm, campsiteType string) (*bookingCart, error) {
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
cart := &bookingCart{
Total: "0.0",
}
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 {
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
}
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
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 {
return cart, 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
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 {
return cart, 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
if f.Guests == nil {
return cart, nil
}
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 {
return cart, 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
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 {
return cart, 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
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 {
return cart, 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
numDogs := 0
if f.Guests.NumberDogs != nil {
numDogs, err = strconv.Atoi(f.Guests.NumberDogs.Val)
if err != nil {
return cart, 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
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
}
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
optionIDs := make([]int, 0, len(typeOptions))
optionUnits := make([]int, 0, len(typeOptions))
for _, option := range typeOptions {
units, _ := strconv.Atoi(option.Input.Val)
if units < 1 {
continue
}
optionMap[option.ID] = option
optionIDs = append(optionIDs, option.ID)
optionUnits = append(optionUnits, units)
}
row := conn.QueryRow(ctx, `
with per_person as (
select count(*) as num_nights
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
, sum(cost.cost_per_night * ceiling(($4::numeric + $5::numeric + $6::numeric) / max_campers::numeric)::integer)::integer as nights
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
, sum(cost_per_adult * $4)::integer as adults
, sum(cost_per_teenager * $5)::integer as teenagers
, sum(cost_per_child * $6)::integer as children
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
, sum(case when $7 > 0 then coalesce(pet.cost_per_night, 0) else 0 end)::integer as dogs
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
, sum(tourist_tax * $4)::integer as tourist_tax
, max(decimal_digits) as decimal_digits
from generate_series($1, $2, interval '1 day') as date(day)
left join season_calendar on season_range @> date.day::date
left join season using (season_id)
left join campsite_type using (company_id)
Add campsite_type_pet_cost relation to hold price of dogs in campsites It is a separate relation, instead of having a field in campsite_type, because not all campsite types allow dogs. I could have added a new field to campsite_type, but then its values it would be meaningless for campsites that do not allow dogs, and a nullable field is not a valid solution because NULL means “unknown”, but we **do** know the price — none. A separate relation encodes the same information without ambiguities nor null values, and, in fact, removed the dogs_allowed field from campsite_type to prevent erroneous status, such as a campsite type that allows dogs without having a cost — even if the cost is zero, it has to be added to the new relation.
2024-02-10 05:18:30 +00:00
left join campsite_type_pet_cost as pet using (campsite_type_id)
left join campsite_type_cost as cost using (campsite_type_id, season_id)
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
left join company using (company_id)
left join currency using (currency_code)
where campsite_type.slug = $3
), per_option as (
select campsite_type_option_id
Allow campsite type option to be just per unit, not per unit per night Customer told us that there are some options, such as towels, that have a fixed price for the whole stay, not a per night price. Thus, had to add a boolean to know whether to use sum or max when computing the cart’s total for each option.
2024-02-11 20:45:00 +00:00
, case when per_night then sum(cost * units)::integer else max(cost * units)::integer end as option_cost
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
from generate_series($1, $2, interval '1 day') as date(day)
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
join season_calendar on season_range @> date.day::date
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
join campsite_type_option_cost using (season_id)
Allow campsite type option to be just per unit, not per unit per night Customer told us that there are some options, such as towels, that have a fixed price for the whole stay, not a per night price. Thus, had to add a boolean to know whether to use sum or max when computing the cart’s total for each option.
2024-02-11 20:45:00 +00:00
join campsite_type_option using (campsite_type_option_id)
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
join unnest($8::integer[], $9::integer[]) as option_units(campsite_type_option_id, units) using (campsite_type_option_id)
Handle the booking cart entirely with HTMx Besides the dynamic final cart, that was already handled by HTMx, i had to check the maximum number of guests, whether the accommodation allows “overflow”, whether dogs are allowed, and that the booking dates were within the campground’s opening and closing dates. I could do all of this with AlpineJS, but then i would have to add the same validation to the backend, prior to accept the payment. Would not make more sense to have them in a single place, namely the backend? With HTMx i can do that. However, i now have to create the form “piecemeal”, because i may not have the whole information when the visitor arrives to the booking page, and i still had the same problem as in commit d2858302efa—parsing the whole form as is would leave guests and options field empty, rather than at their minimum values. One of the fieldsets in that booking form are the arrival and departure dates, that are the sames we use in the campsite type’s page to “preselect” these values. Since now are in a separate struct, i can reuse the same type and validation logic for both pages, making my JavaScript code useless, but requiring HTMx. I think this is a good tradeoff, in fact.
2024-02-10 02:49:44 +00:00
group by campsite_type_option_id
Allow campsite type option to be just per unit, not per unit per night Customer told us that there are some options, such as towels, that have a fixed price for the whole stay, not a per night price. Thus, had to add a boolean to know whether to use sum or max when computing the cart’s total for each option.
2024-02-11 20:45:00 +00:00
, per_night
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
union all select -1, 0
)
select num_nights
, coalesce(to_price(nights, decimal_digits), '')
, coalesce(to_price(adults, decimal_digits), '')
, coalesce(to_price(teenagers, decimal_digits), '')
, coalesce(to_price(children, decimal_digits), '')
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
, coalesce(to_price(dogs, decimal_digits), '')
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
, coalesce(to_price(tourist_tax, decimal_digits), '')
, coalesce(to_price(nights + adults + teenagers + children + tourist_tax + sum(option_cost)::integer, decimal_digits), '')
, array_agg((campsite_type_option_id, to_price(option_cost, decimal_digits)))
from per_person, per_option
group by num_nights
, nights
, adults
, teenagers
, children
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
, dogs
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
, tourist_tax
, decimal_digits
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
`, pgx.QueryResultFormats{pgx.BinaryFormatCode}, arrivalDate, departureDate.AddDate(0, 0, -1), campsiteType, numAdults, numTeenagers, numChildren, numDogs, optionIDs, optionUnits)
Compute and show the “cart” for the booking form I have to ask number and age ranges of hosts of guests for all campsite types, not only those that have price options for adults, children, etc. because i must compute the tourist tax for adults. These numbers will be used to generate de rows for guests when actually creating the booking, which is not done already. To satisfy the campsite types that do have a price per guest, not only per night, i had to add the prices for each range in the campsite_type_cost relation. If a campsite type does not have price per person, then that should be zero; the website then does not display the price. The minimal price for any campsite type is one adult for one night, thus to compute the price i need at least the campsite type, the dates, and the number of adults, that has a minimum of one. I changed the order of the form to ask for these values first, so i can compute the initial price as soon as possible. To help further, i show the <fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
var numNights int
var nights string
var adults string
var teenagers string
var children string
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
var dogs string
Compute and show the “cart” for the booking form I have to ask number and age ranges of hosts of guests for all campsite types, not only those that have price options for adults, children, etc. because i must compute the tourist tax for adults. These numbers will be used to generate de rows for guests when actually creating the booking, which is not done already. To satisfy the campsite types that do have a price per guest, not only per night, i had to add the prices for each range in the campsite_type_cost relation. If a campsite type does not have price per person, then that should be zero; the website then does not display the price. The minimal price for any campsite type is one adult for one night, thus to compute the price i need at least the campsite type, the dates, and the number of adults, that has a minimum of one. I changed the order of the form to ask for these values first, so i can compute the initial price as soon as possible. To help further, i show the <fieldset>s progressively when visitors select options.
2024-02-04 05:37:25 +00:00
var touristTax string
var total string
var optionPrices database.RecordArray
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 = row.Scan(&numNights, &nights, &adults, &teenagers, &children, &dogs, &touristTax, &total, &optionPrices); 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) {
return cart, nil
}
return nil, err
}
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(numNights, nights, locale.PgettextNoop("Night", "cart"))
maybeAddLine(numAdults, adults, locale.PgettextNoop("Adult", "cart"))
maybeAddLine(numTeenagers, teenagers, locale.PgettextNoop("Teenager", "cart"))
maybeAddLine(numChildren, children, locale.PgettextNoop("Child", "cart"))
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
maybeAddLine(numDogs, dogs, locale.PgettextNoop("Dog", "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
for _, el := range optionPrices.Elements {
optionID := el.Fields[0].Get()
if optionID == nil {
continue
}
subtotal := el.Fields[1].Get()
if subtotal == nil {
continue
}
option := optionMap[int(optionID.(int32))]
if option == nil {
continue
}
units, _ := strconv.Atoi(option.Input.Val)
maybeAddLine(units, subtotal.(string), option.Label)
}
maybeAddLine(numAdults, touristTax, locale.PgettextNoop("Tourist tax", "cart"))
if total != "" {
cart.Total = 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
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
}