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

97 lines
3.0 KiB
Go
Raw Normal View History

Split templates and handlers into admin and public I need to check that the user is an employee (or admin) in administration handlers, but i do not want to do it for each handler, because i am bound to forget it. Thus, i added the /admin sub-path for these resources. The public-facing web is the rest of the resources outside /admin, but for now there is only home, to test whether it works as expected or not. The public-facing web can not relay on the user’s language settings, as the guest user has no way to set that. I would be happy to just use the Accept-Language header for that, but apparently Google does not use that header[0], and they give four alternatives: a country-specific domain, a subdomain with a generic top-level domain (gTLD), subdirectories with a gTLD, or URL parameters (e.g., site.com?loc=de). Of the four, Google does not recommend URL parameters, and the customer is already using subdirectories with the current site, therefor that’s what i have chosen. Google also tells me that it is a very good idea to have links between localized version of the same resources, either with <link> elements, Link HTTP response headers, or a sitemap file[1]; they are all equivalent in the eyes of Google. I have choosen the Link response headers way, because for that i can simply “augment” ResponseHeader to automatically add these headers when the response status is 2xx, otherwise i would need to pass down the original URL path until it reaches the template. Even though Camper is supposed to be a “generic”, multi-company application, i think i will stick to the easiest route and write the templates for just the “first” customer. [0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites [1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
/*
* SPDX-FileCopyrightText: 2023 jordi fita mas <jfita@peritasoft.com>
* SPDX-License-Identifier: AGPL-3.0-only
*/
package app
import (
Add public page for campsite type, and function to edit them Had to export and move PublicPage struct to template because i can not import app from campsites/types: app already imports campsite for the http handler, and it, in turn, imports the types package for its own http handler; an import loop. Also had to replace PublicPage.MustRender with a Setup function because the page passed down to html/template was the PublicPage struct, not whatever struct embeds it. I was thinking more of Java inheritance here rather than struct embedding.
2023-08-08 00:29:14 +00:00
"net/http"
Add amenities section and public page 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.
2024-01-27 21:51:41 +00:00
"dev.tandem.ws/tandem/camper/pkg/amenity"
Split templates and handlers into admin and public I need to check that the user is an employee (or admin) in administration handlers, but i do not want to do it for each handler, because i am bound to forget it. Thus, i added the /admin sub-path for these resources. The public-facing web is the rest of the resources outside /admin, but for now there is only home, to test whether it works as expected or not. The public-facing web can not relay on the user’s language settings, as the guest user has no way to set that. I would be happy to just use the Accept-Language header for that, but apparently Google does not use that header[0], and they give four alternatives: a country-specific domain, a subdomain with a generic top-level domain (gTLD), subdirectories with a gTLD, or URL parameters (e.g., site.com?loc=de). Of the four, Google does not recommend URL parameters, and the customer is already using subdirectories with the current site, therefor that’s what i have chosen. Google also tells me that it is a very good idea to have links between localized version of the same resources, either with <link> elements, Link HTTP response headers, or a sitemap file[1]; they are all equivalent in the eyes of Google. I have choosen the Link response headers way, because for that i can simply “augment” ResponseHeader to automatically add these headers when the response status is 2xx, otherwise i would need to pass down the original URL path until it reaches the template. Even though Camper is supposed to be a “generic”, multi-company application, i think i will stick to the easiest route and write the templates for just the “first” customer. [0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites [1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
"dev.tandem.ws/tandem/camper/pkg/auth"
Add the first draft of the booking and payment forms The form is based on the one in the current website, but in a single page instead of split into many pages; possibly each <fieldset> should be in a separate page/view. The idea is for Oriol to check the design and decide how it would be presented to the user, so i needed something to show him first. I hardcoded the **test** data for the customer’s Redsys account. Is this bad? I hope not, but i am not really, really sure. The data sent to Redsys is just a placeholder because there are booking details that i do not know, like what i have to do with the “teenagers” field or the area preferences, thus i can not yet have a booking relation. Nevertheless, had to generate a random order number up to 12-chars in length or Redsys would refuse the payment, claiming that the order is duplicated. The Redsys package is based on the PHP code provided by Redsys themselves, plus some hints at the implementations from various Go packages that did not know why they were so complicated. Had to grant select on table country to guest in order to show the select with the country options. I have changed the “Postal code” input in taxDetails for “Postcode” because this is the spell that it is used in the current web, i did not see a reason to change it—it is an accepted form—, and i did not want to have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
"dev.tandem.ws/tandem/camper/pkg/booking"
Add public page for campsite type, and function to edit them Had to export and move PublicPage struct to template because i can not import app from campsites/types: app already imports campsite for the http handler, and it, in turn, imports the types package for its own http handler; an import loop. Also had to replace PublicPage.MustRender with a Setup function because the page passed down to html/template was the PublicPage struct, not whatever struct embeds it. I was thinking more of Java inheritance here rather than struct embedding.
2023-08-08 00:29:14 +00:00
"dev.tandem.ws/tandem/camper/pkg/campsite"
Split templates and handlers into admin and public I need to check that the user is an employee (or admin) in administration handlers, but i do not want to do it for each handler, because i am bound to forget it. Thus, i added the /admin sub-path for these resources. The public-facing web is the rest of the resources outside /admin, but for now there is only home, to test whether it works as expected or not. The public-facing web can not relay on the user’s language settings, as the guest user has no way to set that. I would be happy to just use the Accept-Language header for that, but apparently Google does not use that header[0], and they give four alternatives: a country-specific domain, a subdomain with a generic top-level domain (gTLD), subdirectories with a gTLD, or URL parameters (e.g., site.com?loc=de). Of the four, Google does not recommend URL parameters, and the customer is already using subdirectories with the current site, therefor that’s what i have chosen. Google also tells me that it is a very good idea to have links between localized version of the same resources, either with <link> elements, Link HTTP response headers, or a sitemap file[1]; they are all equivalent in the eyes of Google. I have choosen the Link response headers way, because for that i can simply “augment” ResponseHeader to automatically add these headers when the response status is 2xx, otherwise i would need to pass down the original URL path until it reaches the template. Even though Camper is supposed to be a “generic”, multi-company application, i think i will stick to the easiest route and write the templates for just the “first” customer. [0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites [1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
"dev.tandem.ws/tandem/camper/pkg/database"
Make home page’s carousel manageable via the database I debated with myself whether to create the home_carousel relation or rather if it would be better to have a single carousel relation for all pages. However, i thought that it would be actually harder to maintain a single relation because i would need an additional column to tell one carrousel from another, and what would that column be? An enum? A foreign key to another relation? home_carousel carries no such issues. I was starting to duplicate logic all over the packages, such as the way to encode media paths or “localization” (l10n) input fields. Therefore, i refactorized them. In the case of media path, i added a function that accepts rows of media, because always need the same columns from the row, and it was yet another repetition if i needed to pass them all the time. Plus, these kind of functions can be called as `table.function`, that make them look like columns from the table; if PostgreSQL implemented virtual generated columns, i would have used that instead. I am not sure whether that media_path function can be immutable. An immutable function is “guaranteed to return the same results given the same arguments forever”, which would be true if the inputs where the hash and the original_filename columns, instead of the whole rows, but i left it as static because i did not know whether PostgreSQL interprets the “same row but with different values” as a different input. That is, whether PostgreSQL’s concept of row is the actual tuple or the space that has a rowid, irrespective of contents; in the latter case, the function can not be immutable. Just to be in the safe side, i left it stable. The home page was starting to grow a bit too much inside the app package, new that it has its own admin handler, and moved it all to a separate package.
2023-09-14 23:05:38 +00:00
"dev.tandem.ws/tandem/camper/pkg/home"
Split templates and handlers into admin and public I need to check that the user is an employee (or admin) in administration handlers, but i do not want to do it for each handler, because i am bound to forget it. Thus, i added the /admin sub-path for these resources. The public-facing web is the rest of the resources outside /admin, but for now there is only home, to test whether it works as expected or not. The public-facing web can not relay on the user’s language settings, as the guest user has no way to set that. I would be happy to just use the Accept-Language header for that, but apparently Google does not use that header[0], and they give four alternatives: a country-specific domain, a subdomain with a generic top-level domain (gTLD), subdirectories with a gTLD, or URL parameters (e.g., site.com?loc=de). Of the four, Google does not recommend URL parameters, and the customer is already using subdirectories with the current site, therefor that’s what i have chosen. Google also tells me that it is a very good idea to have links between localized version of the same resources, either with <link> elements, Link HTTP response headers, or a sitemap file[1]; they are all equivalent in the eyes of Google. I have choosen the Link response headers way, because for that i can simply “augment” ResponseHeader to automatically add these headers when the response status is 2xx, otherwise i would need to pass down the original URL path until it reaches the template. Even though Camper is supposed to be a “generic”, multi-company application, i think i will stick to the easiest route and write the templates for just the “first” customer. [0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites [1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
httplib "dev.tandem.ws/tandem/camper/pkg/http"
Add management of surroundings’ highlights (points of interest) 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.
2024-01-16 00:25:25 +00:00
"dev.tandem.ws/tandem/camper/pkg/legal"
Replace contact page with location 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.
2023-12-21 20:17:04 +00:00
"dev.tandem.ws/tandem/camper/pkg/location"
Add the services page This page is more or less similar to home, in terms of database: it has a carousel and a list of items; in this case, the definition of campsite services. As i said early, when adding the home carousel, this carousel has its own relation and set of functions to manage slides. They are also duplicated in Go code, but i think i will need to refactor it later to a carousel package or something like that, because both relations have the exact same fields and types, so it makes no sense to have twice the same code. I already did it with the CSS and JavaScript code, mostly because it was easier to replace the `.surroundings div` selector with `.carousel`, and because that way i can have a single template that loads and initializes Slick. There is no UI to create or edit service definitions, although there are the SQL functions, because i have no more time now, and Oriol needs to check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
"dev.tandem.ws/tandem/camper/pkg/services"
Add management of surroundings’ highlights (points of interest) 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.
2024-01-16 00:25:25 +00:00
"dev.tandem.ws/tandem/camper/pkg/surroundings"
Add the surroundings static page This page is “highly stylized”, with a masonry-like grid, that i did not know how to generate automatically from data defined in PostgreSQL, therefore with Oriol we agreed to have this one as a static page and we will see what we can do if the customer asks to be able to change it. I was a bit undecided on whether the icons in the bottom part of the page should be defined in the CSS or with style="" and CSS variables, like i do for the campsite type in the home page. At first i thought that it should use CSS variables, mostly for coherence: if another section of the web does it for its background image, why no this one. The difference is that the home page is dynamically created from the database, while this page is static and we know what icons we need, thus it makes more sense to move it to the stylesheet file, because then it will be downloaded by user agents that actually want to use it (e.g., browsers, but not Braille terminals).
2023-09-16 22:11:39 +00:00
"dev.tandem.ws/tandem/camper/pkg/template"
Split templates and handlers into admin and public I need to check that the user is an employee (or admin) in administration handlers, but i do not want to do it for each handler, because i am bound to forget it. Thus, i added the /admin sub-path for these resources. The public-facing web is the rest of the resources outside /admin, but for now there is only home, to test whether it works as expected or not. The public-facing web can not relay on the user’s language settings, as the guest user has no way to set that. I would be happy to just use the Accept-Language header for that, but apparently Google does not use that header[0], and they give four alternatives: a country-specific domain, a subdomain with a generic top-level domain (gTLD), subdirectories with a gTLD, or URL parameters (e.g., site.com?loc=de). Of the four, Google does not recommend URL parameters, and the customer is already using subdirectories with the current site, therefor that’s what i have chosen. Google also tells me that it is a very good idea to have links between localized version of the same resources, either with <link> elements, Link HTTP response headers, or a sitemap file[1]; they are all equivalent in the eyes of Google. I have choosen the Link response headers way, because for that i can simply “augment” ResponseHeader to automatically add these headers when the response status is 2xx, otherwise i would need to pass down the original URL path until it reaches the template. Even though Camper is supposed to be a “generic”, multi-company application, i think i will stick to the easiest route and write the templates for just the “first” customer. [0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites [1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
)
Add public page for campsite type, and function to edit them Had to export and move PublicPage struct to template because i can not import app from campsites/types: app already imports campsite for the http handler, and it, in turn, imports the types package for its own http handler; an import loop. Also had to replace PublicPage.MustRender with a Setup function because the page passed down to html/template was the PublicPage struct, not whatever struct embeds it. I was thinking more of Java inheritance here rather than struct embedding.
2023-08-08 00:29:14 +00:00
type publicHandler struct {
Add management of surroundings’ highlights (points of interest) 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.
2024-01-16 00:25:25 +00:00
home *home.PublicHandler
Add amenities section and public page 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.
2024-01-27 21:51:41 +00:00
amenity *amenity.PublicHandler
Add management of surroundings’ highlights (points of interest) 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.
2024-01-16 00:25:25 +00:00
booking *booking.PublicHandler
campsite *campsite.PublicHandler
legal *legal.PublicHandler
location *location.PublicHandler
services *services.PublicHandler
surroundings *surroundings.PublicHandler
Add public page for campsite type, and function to edit them Had to export and move PublicPage struct to template because i can not import app from campsites/types: app already imports campsite for the http handler, and it, in turn, imports the types package for its own http handler; an import loop. Also had to replace PublicPage.MustRender with a Setup function because the page passed down to html/template was the PublicPage struct, not whatever struct embeds it. I was thinking more of Java inheritance here rather than struct embedding.
2023-08-08 00:29:14 +00:00
}
Split templates and handlers into admin and public I need to check that the user is an employee (or admin) in administration handlers, but i do not want to do it for each handler, because i am bound to forget it. Thus, i added the /admin sub-path for these resources. The public-facing web is the rest of the resources outside /admin, but for now there is only home, to test whether it works as expected or not. The public-facing web can not relay on the user’s language settings, as the guest user has no way to set that. I would be happy to just use the Accept-Language header for that, but apparently Google does not use that header[0], and they give four alternatives: a country-specific domain, a subdomain with a generic top-level domain (gTLD), subdirectories with a gTLD, or URL parameters (e.g., site.com?loc=de). Of the four, Google does not recommend URL parameters, and the customer is already using subdirectories with the current site, therefor that’s what i have chosen. Google also tells me that it is a very good idea to have links between localized version of the same resources, either with <link> elements, Link HTTP response headers, or a sitemap file[1]; they are all equivalent in the eyes of Google. I have choosen the Link response headers way, because for that i can simply “augment” ResponseHeader to automatically add these headers when the response status is 2xx, otherwise i would need to pass down the original URL path until it reaches the template. Even though Camper is supposed to be a “generic”, multi-company application, i think i will stick to the easiest route and write the templates for just the “first” customer. [0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites [1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
func newPublicHandler() *publicHandler {
Add public page for campsite type, and function to edit them Had to export and move PublicPage struct to template because i can not import app from campsites/types: app already imports campsite for the http handler, and it, in turn, imports the types package for its own http handler; an import loop. Also had to replace PublicPage.MustRender with a Setup function because the page passed down to html/template was the PublicPage struct, not whatever struct embeds it. I was thinking more of Java inheritance here rather than struct embedding.
2023-08-08 00:29:14 +00:00
return &publicHandler{
Add management of surroundings’ highlights (points of interest) 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.
2024-01-16 00:25:25 +00:00
home: home.NewPublicHandler(),
Add amenities section and public page 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.
2024-01-27 21:51:41 +00:00
amenity: amenity.NewPublicHandler(),
Add management of surroundings’ highlights (points of interest) 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.
2024-01-16 00:25:25 +00:00
booking: booking.NewPublicHandler(),
campsite: campsite.NewPublicHandler(),
legal: legal.NewPublicHandler(),
location: location.NewPublicHandler(),
services: services.NewPublicHandler(),
surroundings: surroundings.NewPublicHandler(),
Add public page for campsite type, and function to edit them Had to export and move PublicPage struct to template because i can not import app from campsites/types: app already imports campsite for the http handler, and it, in turn, imports the types package for its own http handler; an import loop. Also had to replace PublicPage.MustRender with a Setup function because the page passed down to html/template was the PublicPage struct, not whatever struct embeds it. I was thinking more of Java inheritance here rather than struct embedding.
2023-08-08 00:29:14 +00:00
}
Split templates and handlers into admin and public I need to check that the user is an employee (or admin) in administration handlers, but i do not want to do it for each handler, because i am bound to forget it. Thus, i added the /admin sub-path for these resources. The public-facing web is the rest of the resources outside /admin, but for now there is only home, to test whether it works as expected or not. The public-facing web can not relay on the user’s language settings, as the guest user has no way to set that. I would be happy to just use the Accept-Language header for that, but apparently Google does not use that header[0], and they give four alternatives: a country-specific domain, a subdomain with a generic top-level domain (gTLD), subdirectories with a gTLD, or URL parameters (e.g., site.com?loc=de). Of the four, Google does not recommend URL parameters, and the customer is already using subdirectories with the current site, therefor that’s what i have chosen. Google also tells me that it is a very good idea to have links between localized version of the same resources, either with <link> elements, Link HTTP response headers, or a sitemap file[1]; they are all equivalent in the eyes of Google. I have choosen the Link response headers way, because for that i can simply “augment” ResponseHeader to automatically add these headers when the response status is 2xx, otherwise i would need to pass down the original URL path until it reaches the template. Even though Camper is supposed to be a “generic”, multi-company application, i think i will stick to the easiest route and write the templates for just the “first” customer. [0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites [1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
}
Move the locales parameter inside Company struct. I realized that locales should be company-dependent: we could have two companies that show pages in a different subset of the application locales. It is not the case now, because despite being a “multicompany application”, it is intended for a single customer, but still makes sense to include it in Company, even if the subset is the same set as the application’s.
2023-08-07 08:51:57 +00:00
func (h *publicHandler) Handler(user *auth.User, company *auth.Company, conn *database.Conn) http.Handler {
Split templates and handlers into admin and public I need to check that the user is an employee (or admin) in administration handlers, but i do not want to do it for each handler, because i am bound to forget it. Thus, i added the /admin sub-path for these resources. The public-facing web is the rest of the resources outside /admin, but for now there is only home, to test whether it works as expected or not. The public-facing web can not relay on the user’s language settings, as the guest user has no way to set that. I would be happy to just use the Accept-Language header for that, but apparently Google does not use that header[0], and they give four alternatives: a country-specific domain, a subdomain with a generic top-level domain (gTLD), subdirectories with a gTLD, or URL parameters (e.g., site.com?loc=de). Of the four, Google does not recommend URL parameters, and the customer is already using subdirectories with the current site, therefor that’s what i have chosen. Google also tells me that it is a very good idea to have links between localized version of the same resources, either with <link> elements, Link HTTP response headers, or a sitemap file[1]; they are all equivalent in the eyes of Google. I have choosen the Link response headers way, because for that i can simply “augment” ResponseHeader to automatically add these headers when the response status is 2xx, otherwise i would need to pass down the original URL path until it reaches the template. Even though Camper is supposed to be a “generic”, multi-company application, i think i will stick to the easiest route and write the templates for just the “first” customer. [0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites [1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
var head string
head, r.URL.Path = httplib.ShiftPath(r.URL.Path)
switch head {
case "":
Make home page’s carousel manageable via the database I debated with myself whether to create the home_carousel relation or rather if it would be better to have a single carousel relation for all pages. However, i thought that it would be actually harder to maintain a single relation because i would need an additional column to tell one carrousel from another, and what would that column be? An enum? A foreign key to another relation? home_carousel carries no such issues. I was starting to duplicate logic all over the packages, such as the way to encode media paths or “localization” (l10n) input fields. Therefore, i refactorized them. In the case of media path, i added a function that accepts rows of media, because always need the same columns from the row, and it was yet another repetition if i needed to pass them all the time. Plus, these kind of functions can be called as `table.function`, that make them look like columns from the table; if PostgreSQL implemented virtual generated columns, i would have used that instead. I am not sure whether that media_path function can be immutable. An immutable function is “guaranteed to return the same results given the same arguments forever”, which would be true if the inputs where the hash and the original_filename columns, instead of the whole rows, but i left it as static because i did not know whether PostgreSQL interprets the “same row but with different values” as a different input. That is, whether PostgreSQL’s concept of row is the actual tuple or the space that has a rowid, irrespective of contents; in the latter case, the function can not be immutable. Just to be in the safe side, i left it stable. The home page was starting to grow a bit too much inside the app package, new that it has its own admin handler, and moved it all to a separate package.
2023-09-14 23:05:38 +00:00
h.home.Handler(user, company, conn).ServeHTTP(w, r)
Add amenities section and public page 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.
2024-01-27 21:51:41 +00:00
case "amenities":
h.amenity.Handler(user, company, conn).ServeHTTP(w, r)
Add the first draft of the booking and payment forms The form is based on the one in the current website, but in a single page instead of split into many pages; possibly each <fieldset> should be in a separate page/view. The idea is for Oriol to check the design and decide how it would be presented to the user, so i needed something to show him first. I hardcoded the **test** data for the customer’s Redsys account. Is this bad? I hope not, but i am not really, really sure. The data sent to Redsys is just a placeholder because there are booking details that i do not know, like what i have to do with the “teenagers” field or the area preferences, thus i can not yet have a booking relation. Nevertheless, had to generate a random order number up to 12-chars in length or Redsys would refuse the payment, claiming that the order is duplicated. The Redsys package is based on the PHP code provided by Redsys themselves, plus some hints at the implementations from various Go packages that did not know why they were so complicated. Had to grant select on table country to guest in order to show the select with the country options. I have changed the “Postal code” input in taxDetails for “Postcode” because this is the spell that it is used in the current web, i did not see a reason to change it—it is an accepted form—, and i did not want to have inconsistencies between forms.
2023-10-19 19:37:34 +00:00
case "booking":
h.booking.Handler(user, company, conn).ServeHTTP(w, r)
Add the campground page For now, this page only shows the map, that i had to create a new “files” template function to include it as an extra template file.
2023-10-06 20:14:11 +00:00
case "campground":
campgroundHandler(user, company, conn).ServeHTTP(w, r)
Add public page for campsite type, and function to edit them Had to export and move PublicPage struct to template because i can not import app from campsites/types: app already imports campsite for the http handler, and it, in turn, imports the types package for its own http handler; an import loop. Also had to replace PublicPage.MustRender with a Setup function because the page passed down to html/template was the PublicPage struct, not whatever struct embeds it. I was thinking more of Java inheritance here rather than struct embedding.
2023-08-08 00:29:14 +00:00
case "campsites":
h.campsite.Handler(user, company, conn).ServeHTTP(w, r)
Add management of legal texts
2023-12-22 01:23:18 +00:00
case "legal":
h.legal.Handler(user, company, conn).ServeHTTP(w, r)
Replace contact page with location 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.
2023-12-21 20:17:04 +00:00
case "location":
h.location.Handler(user, company, conn).ServeHTTP(w, r)
Add the services page This page is more or less similar to home, in terms of database: it has a carousel and a list of items; in this case, the definition of campsite services. As i said early, when adding the home carousel, this carousel has its own relation and set of functions to manage slides. They are also duplicated in Go code, but i think i will need to refactor it later to a carousel package or something like that, because both relations have the exact same fields and types, so it makes no sense to have twice the same code. I already did it with the CSS and JavaScript code, mostly because it was easier to replace the `.surroundings div` selector with `.carousel`, and because that way i can have a single template that loads and initializes Slick. There is no UI to create or edit service definitions, although there are the SQL functions, because i have no more time now, and Oriol needs to check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
case "services":
h.services.Handler(user, company, conn).ServeHTTP(w, r)
Add the surroundings static page This page is “highly stylized”, with a masonry-like grid, that i did not know how to generate automatically from data defined in PostgreSQL, therefore with Oriol we agreed to have this one as a static page and we will see what we can do if the customer asks to be able to change it. I was a bit undecided on whether the icons in the bottom part of the page should be defined in the CSS or with style="" and CSS variables, like i do for the campsite type in the home page. At first i thought that it should use CSS variables, mostly for coherence: if another section of the web does it for its background image, why no this one. The difference is that the home page is dynamically created from the database, while this page is static and we know what icons we need, thus it makes more sense to move it to the stylesheet file, because then it will be downloaded by user agents that actually want to use it (e.g., browsers, but not Braille terminals).
2023-09-16 22:11:39 +00:00
case "surroundings":
Add management of surroundings’ highlights (points of interest) 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.
2024-01-16 00:25:25 +00:00
h.surroundings.Handler(user, company, conn).ServeHTTP(w, r)
Split templates and handlers into admin and public I need to check that the user is an employee (or admin) in administration handlers, but i do not want to do it for each handler, because i am bound to forget it. Thus, i added the /admin sub-path for these resources. The public-facing web is the rest of the resources outside /admin, but for now there is only home, to test whether it works as expected or not. The public-facing web can not relay on the user’s language settings, as the guest user has no way to set that. I would be happy to just use the Accept-Language header for that, but apparently Google does not use that header[0], and they give four alternatives: a country-specific domain, a subdomain with a generic top-level domain (gTLD), subdirectories with a gTLD, or URL parameters (e.g., site.com?loc=de). Of the four, Google does not recommend URL parameters, and the customer is already using subdirectories with the current site, therefor that’s what i have chosen. Google also tells me that it is a very good idea to have links between localized version of the same resources, either with <link> elements, Link HTTP response headers, or a sitemap file[1]; they are all equivalent in the eyes of Google. I have choosen the Link response headers way, because for that i can simply “augment” ResponseHeader to automatically add these headers when the response status is 2xx, otherwise i would need to pass down the original URL path until it reaches the template. Even though Camper is supposed to be a “generic”, multi-company application, i think i will stick to the easiest route and write the templates for just the “first” customer. [0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites [1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
default:
http.NotFound(w, r)
}
})
}
Add the contact page, containing a map with the company location I was not sure whether to use PostGIS to store the GPS location of the company, as i am sure i will only use that point just to show the map. However, just in case, it is not a big deal. There is no way to change that from the administration pages for now, because of time constraints, and it is very unlikely that they will change the campgrounds’ location in the near future. The location is in a separate table because i did not want to have to change every test file, to be honest, but this also makes the map “optional” without the need for NULL values. I added the contact address to every public page because the new design adds it to the footer, so i will be needing it everywhere, just like the menu.
2023-10-06 19:21:00 +00:00
Add the campground page For now, this page only shows the map, that i had to create a new “files” template function to include it as an extra template file.
2023-10-06 20:14:11 +00:00
func campgroundHandler(user *auth.User, company *auth.Company, conn *database.Conn) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
var head string
head, r.URL.Path = httplib.ShiftPath(r.URL.Path)
switch head {
case "":
switch r.Method {
case http.MethodGet:
page := template.NewPublicPage()
page.Setup(r, user, company, conn)
template.MustRenderPublicFiles(w, r, user, company, page, "campground.gohtml", "web/templates/campground_map.svg")
default:
httplib.MethodNotAllowed(w, r, http.MethodGet)
}
default:
http.NotFound(w, r)
}
})
}