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.
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.
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.
Had to change the link to the current language version of the page by a
button, to prevent following a link when trying to expand the submenu.
At first i did this with an `onclick="return false"` bullshit, but the
link was the wrong thing to do here, and it was there only to satisfy
Google et al. They will have to with the links in head.
Also made the link and buttons larger to make it easier to hit them with
finger.
Customer told us that the minimum number of nights is per campsite type,
not per season. And he wants this, along with the maximum number of
nights, in order to limit the range of departure dates that guests can
choose when booking.
It seems that we have to highlight the map zones too. On the previous
website, they had a mouseover effect that displayed a tooltip, but here
we can not do that because we use the mouse to select accommodations.
This is just a test to see whether Oriol likes how it is shown, thus the
red is likely to change to something else more pleasant to look at.
The “overflow” is for when people want to book plots for more guests
than is permitted, which the system would need to add a new plot to the
“shopping cart”, as it were; not implemented yet.
The ask zone preferences is to whether show the corresponding input on
the booking form, that it was done implicitly when the campsite type had
options, because up until now it was only for plots, but it is no longer
the case, thus i need to know when to show it; now it is explicit.
This is more or less the same as the campsites, as public information
goes, but for buildings and other amenities that the camping provides
that are not campsites.
A small page with a brief description, carousel, and feature list of
each individual accommodation.
Most of the relations and functions for carousel and features are like
the ones for campsite types, but i had to use the accommodation’s label
to find them, because they do not have slugs; i did not even though
these would be public, and they already have a label, although not
unique for all companies, like UUID slugs are.
I can not use <a> in that map because Leaflet handles the mouse over
before the anchors sees it, thus it is impossible to click on them; i
have to use a Leaflet layer.
Fortunately, i can just use the <path>’s coordinates as
the polygon points, because with CRS.Simple the coordinates map to
pixel, except for the reversed Y/latitude coordinate. Unfortunately,
<path> coordinates are not straightforward to get: I have to follow the
drawing coordinates, taking into account the current transformation
(CTM), and keeping the last point around for relative coordinates.
Bézier curves are simplified to a straight line from start to end.
There is one single accommodation that started with a relative move
command (m), which apparently have to be treated as an absolute
move (M), but subsequent pairs are treated as relative coordinates[0].
It was easier for me to convert that relative move to absolute and add
a relative lineto command (l) to the next pair.
For now, all i do is highlight the accommodation and zoom it on click,
because i do not know how i should the accommodation’s information.
[0]: https://www.w3.org/TR/SVG11/paths.html#PathDataMovetoCommands
In the map i added in e3503187d, paths around each accommodation
inherited the fill and stroke from the group, thus i could just override
that fill at the anchor level, but the current map sets the fill to each
accommodation’s path, party because the text is not a path too, partly
because Affinity is a visual tool only and does not give a shit about
mark up.
If we keep the text in a group, however, we can set the fill of the area
using CSS too, although it is not nice due to `!important`, but still.
There was a plot, however, #93, that had the area in a group too, and
i had to remove that group manually.
It seems that the prefix got removed in one of the edits.
Also, Affinity does not give a fuck to what classes we give to the
elements, and just removes them, thus .guest-only no longer matches, and
had to hide the layers by id. Hope they hold this time.
It is virtually impossible to see when such a field fails prior to
submit the form, unless you happen to have the correct language selected
at the time.
Leave it to the backend’s validation for now.
Otherwise, the browser assumes they are two different resources, because
i am telling it so with the two URI, and loads the same file twice,
triggering the execution of startup functions, such as the ones that
convert textareas to CKEditor divs, twice.
Apparently, each campsite type could have different check-in and
check-out times, thus i need them in the database.
I thought about using an integer or a datetime field, but customer seems
to want a text field to maybe add “before” and “after” there as well.
Translatable text it is.
I also changed the translatable link to not include any HTML, because it
meant that i had to retranslate them just to add a new attribute, that
does not make much sense—the attribute is not even translatable, thus
all translations must include it verbatim.
I tried to use ../, and ../../ to make the routes relatives, but it
would not work well because the same page would have two URLs, one
ending with slash and another without, and the relative links would be
different on each case.
This is mostly because it is required for the “Digital Kit”, but it also
works in our favor because now i can version the URL to the static
resources.
Go 1.18 adds the info from git if the package is build from a git
repository, but this is not the case in OBS, so i instead relay on a
constant for the version number. This constant is “updated” by Debian’s
rules, mostly due to the discussion in [0].
[0]: https://github.com/golang/go/issues/22706
It is for people aged 17 or olded, not 16. I was confused by the
expression “over 16”, that **seems** to mean 17 or older, but actually
includes people aged 16, too.
There is no way, for now, to add, edit or remove users, because
currently we only need to list users.
I can not give admins access to the user table, for security
permissions, so i had to create a new view. I could name it also ‘user’
in ‘camper’ scheme, but then i was afraid i would have problems with
unit tests and their search_path, so instead i called it
‘company_user_profile’, which is like ‘user_profile’ but for all users
in ‘company_user’.
I created a new Go package for it, rather than add the admin handler in
‘auth’, because ‘template’ depends on ‘auth’, and rendering from ‘auth’
would cause a dependency loop.
I needed to have the roles in gettext to translate them, but there is
no obvious place where to put the call to PgettextNoop. For now, there
are in ‘NewAdminHandler’ because it is called once in the application’s
lifetime and they actually do not matter much.
Oriol did not like that this carousel was different from the rest, and
wanted to have it like the rest, but showing only one slide at a time,
like the customer wants.
He also wanted the arrows for **all** carousels to be in the top-right
corner instead of bottom-right, mostly because the customer complains
that she does not see the arrows if they are on the bottom, and Oriol
does not like the arrows to the sides.
This is a separate carousel from the one displayed at the bottom with
location info; it is, i suppose, a carousel for the hero image.
For the database, it works exactly as the home carousel, but on the
front had to use AlpineJS instead of Slick because it needs to show a
text popping up from the bottom when the slide is show, something i do
not know how to do in Slick.
It now makes no sense to have the carousel inside the “nature” section,
because the heading is no longer in there, and moved it out into a new
“hero” div.
Since i now have two carousels in home, i had to add additional
attributes to carousel.AdminHandler to know which URL to point to when
POSTing, PUTting, or redirecting.
I was using a <form> to delete slides and other such elements before
adding the form to sort these same elements with drag and drop, without
realizing that i was wrapping the existing delete <form>s, that now
would not submit properly—they were submitting the sort form instead.
jordi fita mas
oriol carbonell pujolàs