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.
Previously, the only type with options was plots, that was always the
third fieldset, which was the wrong thing to hardcode, but it was done
in a hurry. Now there are more types with options, so we have to do it
properly.
Without the position relative, the booking button is no longer on top
of the carousel depending on the screen resolution, and Oriol wants less
gap between the carrousel and the next section.
I misunderstood Oriol, and what he really wanted was to have the arrows
on top of the image, not just move the arrows from below to above. Thus,
I no longer need the carrousel to be a flex because the buttons are now
absolutely position (slick.css already sets the container to relative
position).
These arrows need to be visually inside a single container, to have a
white background, but Slick adds the two arrows separately. I had to
move them close together, remove the radius from the “common edge”, and
use padding to “move” the arrows, rather than translation, in order to
avoid showing a gap.
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.
Customer does not want the new “masonry-like” design of the surroundings
page, and wants the same style they already had: a regular list with
text and photo, alternating the photo’s side.
And, of course, they want to be able to add and edit them themselves. It
is like another carousel, but with an additional rich-text description.
The photos that we had in that page are no longer of use.
The pets icon is just the same as the notpet but without the diagonal
bar.
The price is hardcoded in the query for now, as there is no field
in the campsite type.
It is better for mobile users, as they can zoom and pan the map in their
small screens.
Had to increase header’s z-index or the zoom controls would be on top
of it.
Customer does not want a contact page, but a page where they can write
the direction on how to reach the campground, with a Google map embed
instead of using Leaflet, because Google Maps shows the reviews right
in the map.
That means i had to replace the GPS locations with XML fields for the
customer to write. In all four languages.
This time i tried a translation approach inspired by PrestaShop: instead
of opening a new page for each language, i have all languages in the
same page and use AlpineJS to show just a single language. It is far
easier to write the translations, even though you do not have the source
text visible, specially in this section that there is no place for me
to put the language links.
Customer does not want the next slide to show partially; either it shows
theo whole slide, or not at all.
Had to remove the min-width for campsite type’s spiel, or it would make
the whole thing fall over, i do not know why; possibly because slick
could not reduce the width to its expected value.
Oriol does not want to waste so much vertical space for the calendar,
and wants it to show in a carousel, initially with only 6 months, and
loading the next three each time the user scrolls past the last.
I now use HTMx in the public page too for this auto-loading behavior,
based on their “infinite scroll” example[0].
Had to put the /calendar URI inside campsites because in the
calendar.gohtml i do not know the current type’s UUID, and can not use
a relative URL to “add subdirectories”, because the type does not end
with a slash.
Had to change season.CollectCalendar to expect the first month and a
number of months to show, to be able to load only 6 or 3 months after
the current, for the initial carousel content, or after the last month
of the carousel.
[0]: https://htmx.org/examples/infinite-scroll/
I had to export the Calendar type from Season to use it from
campsite/types, and also renamed them because season.SeasonCalendar is
a bit redundant compared to just season.Calendar.
I still have not added the HTMx code to switch year because i am not
sure whether Oriol will want to show a whole year or just half a year.
The calculation for the text color taking into account the contrast with
the background is from [0].
[0]: https://www.smashingmagazine.com/2020/07/css-techniques-legibility/#foreground-contrast
This is the text that introduces the carousel; it is not a spiel, but
this is what i call it.
It turns out that this text needs to have paragraphs and headings, much
like home’s slider, rather than the one in services page, thus no need
to change its font size or to align all items in the carousel in the
middle.
I can not reuse the carousel package because these carousels need the
campsite site’s slug as a first parameters: i can not have a relation
per campsite type, as i do in home and services pages, because the
campsite types are added by administration types; even if i had a
single relation for slides of home and services pages, these would go
in a different relation due to the foreign key to campsite type.
What i could reuse, however, is the Slide and SlideEntry types from
that package, although i had to export carousel.Translation to be usable
from the types package. I should change that to use locale.Translation,
but this was the easier option, or i would need to change the queries
and templates for carousel package too.
Besides that, they work exactly like the slides in home and services
pages.
oriol carbonell pujolàs
jordi fita mas