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 <jordi@tandem.blog>
|
2024-01-16 16:58:49 +00:00
|
|
|
|
SPDX-FileCopyrightText: 2023 Oriol Carbonell <info@oriolcarbonell.cat>
|
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-License-Identifier: AGPL-3.0-only
|
|
|
|
|
|
-->
|
2023-10-06 20:02:59 +00:00
|
|
|
|
{{- /*gotype: dev.tandem.ws/tandem/camper/pkg/template.PublicPage*/ -}}
|
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
|
|
|
|
<!doctype html>
|
|
|
|
|
|
<html lang="{{ currentLocale }}">
|
|
|
|
|
|
<head>
|
|
|
|
|
|
<meta charset="utf-8">
|
|
|
|
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
|
|
|
|
<title>{{ template "title" . }} — {{( gettext "Campsite Montagut" )}}</title>
|
2023-09-05 02:40:48 +00:00
|
|
|
|
<link rel="preload" href="/static/fonts/MabryPro-Regular.woff2" as="font" type="font/woff2" crossorigin>
|
|
|
|
|
|
<link rel="preload" href="/static/fonts/MabryPro-Bold.woff2" as="font" type="font/woff2" crossorigin>
|
2024-01-21 19:50:04 +00:00
|
|
|
|
<link rel="stylesheet" media="screen" href="/static/public.css?v={{ camperVersion }}">
|
|
|
|
|
|
<link rel="stylesheet" media="screen" href="/static/icons.css?v={{ camperVersion }}">
|
Add the language switched to the public layout
The language switcher needs the same information as languageLinks
needed, namely the list of locales and the current Path, to construct
the URI to all alternate versions. However, in this case i need access
to this data in the template context, to build the list of links.
At first i use request’s context to hold the list of available locales
from application, and it worked, possibly without ill-effects, but i
realized that i was doing it just to avoid a new parameter. Or, more
precise, an _explicit_ parameter; the context was used to skip the
inner functions between app and template.MustRenderPublic, but the
parameter was there all the same.
Finally, i thought that some handler might want to filter the list of
locales to show only the ones that it has a translation of. In that
case, i would need to extract the locales from the context, filter it,
and create a new request with the updated context. That made little
sense, and made me add the explicit locales parameter.
Since now the template has the same data as languageLinks, there is
little point of having the link in the HTTP response headers, and added
the <link> elements to <head>.
I thought that maybe i could avoid these <links> as they give the exact
same data as the language switch, but Google says nothing of using
regular anchors to gather information about localized versions of the
document[0], thus i opted to be conservative. One can reason that the
<head> has more weight for Google, as most sites with user-generated
content, which could contain these anchors, rarely allow users to edit
the <head>.
[0]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-06 03:53:52 +00:00
|
|
|
|
{{ range .LocalizedAlternates -}}
|
2024-01-21 20:12:12 +00:00
|
|
|
|
<link rel="alternate" hreflang="{{ .Lang }}" href="{{ .HRef }}">
|
Add the language switched to the public layout
The language switcher needs the same information as languageLinks
needed, namely the list of locales and the current Path, to construct
the URI to all alternate versions. However, in this case i need access
to this data in the template context, to build the list of links.
At first i use request’s context to hold the list of available locales
from application, and it worked, possibly without ill-effects, but i
realized that i was doing it just to avoid a new parameter. Or, more
precise, an _explicit_ parameter; the context was used to skip the
inner functions between app and template.MustRenderPublic, but the
parameter was there all the same.
Finally, i thought that some handler might want to filter the list of
locales to show only the ones that it has a translation of. In that
case, i would need to extract the locales from the context, filter it,
and create a new request with the updated context. That made little
sense, and made me add the explicit locales parameter.
Since now the template has the same data as languageLinks, there is
little point of having the link in the HTTP response headers, and added
the <link> elements to <head>.
I thought that maybe i could avoid these <links> as they give the exact
same data as the language switch, but Google says nothing of using
regular anchors to gather information about localized versions of the
document[0], thus i opted to be conservative. One can reason that the
<head> has more weight for Google, as most sites with user-generated
content, which could contain these anchors, rarely allow users to edit
the <head>.
[0]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-06 03:53:52 +00:00
|
|
|
|
{{ end }}
|
2023-10-18 19:06:41 +00:00
|
|
|
|
<script src="/static/htmx@1.9.3.min.js"></script>
|
Add the language switched to the public layout
The language switcher needs the same information as languageLinks
needed, namely the list of locales and the current Path, to construct
the URI to all alternate versions. However, in this case i need access
to this data in the template context, to build the list of links.
At first i use request’s context to hold the list of available locales
from application, and it worked, possibly without ill-effects, but i
realized that i was doing it just to avoid a new parameter. Or, more
precise, an _explicit_ parameter; the context was used to skip the
inner functions between app and template.MustRenderPublic, but the
parameter was there all the same.
Finally, i thought that some handler might want to filter the list of
locales to show only the ones that it has a translation of. In that
case, i would need to extract the locales from the context, filter it,
and create a new request with the updated context. That made little
sense, and made me add the explicit locales parameter.
Since now the template has the same data as languageLinks, there is
little point of having the link in the HTTP response headers, and added
the <link> elements to <head>.
I thought that maybe i could avoid these <links> as they give the exact
same data as the language switch, but Google says nothing of using
regular anchors to gather information about localized versions of the
document[0], thus i opted to be conservative. One can reason that the
<head> has more weight for Google, as most sites with user-generated
content, which could contain these anchors, rarely allow users to edit
the <head>.
[0]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-06 03:53:52 +00:00
|
|
|
|
{{- block "head" . }}{{ end }}
|
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
|
|
|
|
</head>
|
|
|
|
|
|
<body>
|
2023-09-05 02:40:48 +00:00
|
|
|
|
<a href="#content">{{( gettext "Skip to main content" )}}</a>
|
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
|
|
|
|
<header>
|
2023-12-20 19:39:26 +00:00
|
|
|
|
{{ with .CompanyAddress -}}
|
|
|
|
|
|
<address>
|
2024-01-11 19:56:35 +00:00
|
|
|
|
<a href="tel:{{ replaceAll .Phone " " "" }}">{{ replaceAll .Phone "+" "00 " }}</a>
|
2023-12-20 19:39:26 +00:00
|
|
|
|
<a href="mailto:{{ .Email }}">{{ .Email }}</a>
|
|
|
|
|
|
</address>
|
|
|
|
|
|
{{- end }}
|
2023-12-21 21:39:58 +00:00
|
|
|
|
{{ if .LocalizedAlternates -}}
|
|
|
|
|
|
<nav>
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li class="has-submenu">{{ range .LocalizedAlternates -}}
|
|
|
|
|
|
{{ if eq .Lang currentLocale }}{{ template "alternateAnchor" . }}{{ end }}
|
|
|
|
|
|
{{- end }}
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
{{ range .LocalizedAlternates }}{{ if ne .Lang currentLocale -}}
|
|
|
|
|
|
<li>{{ template "alternateAnchor" . }}</li>
|
|
|
|
|
|
{{ end }}{{ end }}
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</nav>
|
|
|
|
|
|
{{- end }}
|
2023-12-20 19:39:26 +00:00
|
|
|
|
<h1><a href="/{{ currentLocale }}/"><span class="logo">◭</span><span
|
|
|
|
|
|
class="name">{{( gettext "Campsite Montagut" )}}</span></a></h1>
|
2023-09-11 03:43:36 +00:00
|
|
|
|
<input type="checkbox" id="menuShowHide">
|
2024-01-10 18:41:57 +00:00
|
|
|
|
<label for="menuShowHide">{{( gettext "Menu" )}}</label>
|
2023-09-11 03:13:57 +00:00
|
|
|
|
<nav>
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li><a href="/{{ currentLocale }}/">{{( pgettext "Home" "title" )}}</a></li>
|
2023-10-06 20:14:11 +00:00
|
|
|
|
<li><a href="/{{ currentLocale }}/campground">{{( pgettext "Campground" "title" )}}</a></li>
|
2023-09-11 03:13:57 +00:00
|
|
|
|
{{ with .Menu -}}
|
2023-08-08 00:29:14 +00:00
|
|
|
|
{{ if .CampsiteTypes -}}
|
2023-09-11 03:13:57 +00:00
|
|
|
|
<li class="has-submenu">
|
2023-10-06 16:58:24 +00:00
|
|
|
|
<button type="button">{{( pgettext "Campsites" "title" )}}</button>
|
2023-09-11 03:13:57 +00:00
|
|
|
|
<ul>
|
2023-08-08 00:29:14 +00:00
|
|
|
|
{{ range .CampsiteTypes -}}
|
|
|
|
|
|
<li><a href="{{ .HRef }}">{{ .Label }}</a></li>
|
|
|
|
|
|
{{ end }}
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
{{- end }}
|
2023-09-11 03:13:57 +00:00
|
|
|
|
{{- end }}
|
2023-10-06 09:37:25 +00:00
|
|
|
|
<li><a href="/{{ currentLocale }}/services">{{( pgettext "Services" "title" )}}</a></li>
|
|
|
|
|
|
<li><a href="/{{ currentLocale }}/surroundings">{{( pgettext "Surroundings" "title" )}}</a></li>
|
2023-12-21 20:17:04 +00:00
|
|
|
|
<li><a href="/{{ currentLocale }}/location">{{( pgettext "Location" "title" )}}</a></li>
|
2023-12-21 18:11:20 +00:00
|
|
|
|
<li class="boto-reserva"><a href="/{{ currentLocale }}/booking">{{( pgettext "Booking" "title" )}}</a></li>
|
2023-09-11 03:13:57 +00:00
|
|
|
|
{{ if .LocalizedAlternates -}}
|
|
|
|
|
|
<li class="has-submenu">{{ range .LocalizedAlternates -}}
|
|
|
|
|
|
{{ if eq .Lang currentLocale }}{{ template "alternateAnchor" . }}{{ end }}
|
|
|
|
|
|
{{- end }}
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
{{ range .LocalizedAlternates }}{{ if ne .Lang currentLocale -}}
|
|
|
|
|
|
<li>{{ template "alternateAnchor" . }}</li>
|
|
|
|
|
|
{{ end }}{{ end }}
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
{{- end }}
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</nav>
|
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
|
|
|
|
</header>
|
|
|
|
|
|
<main id="content">
|
|
|
|
|
|
{{- template "content" . }}
|
|
|
|
|
|
</main>
|
2023-10-06 20:02:59 +00:00
|
|
|
|
<footer>
|
|
|
|
|
|
<div>
|
|
|
|
|
|
<section>
|
|
|
|
|
|
<h2>{{( pgettext "Sections" "title" )}}</h2>
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li><a href="/{{ currentLocale }}/">{{( pgettext "Home" "title" )}}</a></li>
|
2023-10-06 20:14:11 +00:00
|
|
|
|
<li><a href="/{{ currentLocale }}/campground">{{( pgettext "Campground" "title" )}}</a></li>
|
2023-10-06 20:02:59 +00:00
|
|
|
|
<li><a href="/{{ currentLocale }}/services">{{( pgettext "Services" "title" )}}</a></li>
|
|
|
|
|
|
<li><a href="/{{ currentLocale }}/surroundings">{{( pgettext "Surroundings" "title" )}}</a></li>
|
2023-12-21 20:17:04 +00:00
|
|
|
|
<li><a href="/{{ currentLocale }}/location">{{( pgettext "Location" "title" )}}</a></li>
|
2023-10-06 20:02:59 +00:00
|
|
|
|
</ul>
|
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
|
|
{{ with .Menu -}}
|
|
|
|
|
|
{{ if .CampsiteTypes -}}
|
|
|
|
|
|
<section>
|
|
|
|
|
|
<h2>{{( pgettext "Campsites" "title" )}}</h2>
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
{{ range .CampsiteTypes -}}
|
|
|
|
|
|
<li><a href="{{ .HRef }}">{{ .Label }}</a></li>
|
|
|
|
|
|
{{ end }}
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</section>
|
|
|
|
|
|
{{- end }}
|
|
|
|
|
|
{{- end }}
|
|
|
|
|
|
|
2023-12-20 12:02:56 +00:00
|
|
|
|
<section>
|
2023-12-21 20:17:04 +00:00
|
|
|
|
<h2>{{ (pgettext "Opening" "title" )}}</h2>
|
|
|
|
|
|
{{ .OpeningDates }}
|
2023-12-20 12:02:56 +00:00
|
|
|
|
</section>
|
|
|
|
|
|
|
2023-10-06 20:02:59 +00:00
|
|
|
|
<section>
|
|
|
|
|
|
<h2>{{ .CompanyAddress.TradeName }}</h2>
|
|
|
|
|
|
{{ template "companyAddress" .CompanyAddress }}
|
2023-10-14 19:59:36 +00:00
|
|
|
|
{{ printf ( gettext "<abbr title=\"Catalonia Tourism Registry\">RTC</abbr> <abbr title=\"Number\">#</abbr>%s") .CompanyAddress.RTCNumber | raw }}
|
2024-01-11 19:56:35 +00:00
|
|
|
|
<div class="camping-association">
|
|
|
|
|
|
<img src="/static/camping-association/Reconeixement.gif" alt="Alan Rogers">
|
|
|
|
|
|
<img src="/static/camping-association/acsi.jpg" alt="ACSI">
|
|
|
|
|
|
<img src="/static/camping-association/logofecc4.gif" alt="Federación Española de Clubes Capistas">
|
|
|
|
|
|
<img src="/static/camping-association/anwb.png" alt="anwb">
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</section>
|
2023-10-06 20:02:59 +00:00
|
|
|
|
</div>
|
2023-12-21 20:18:22 +00:00
|
|
|
|
<span>© {{( gettext "Campsite Montagut" )}} | 1994–2023</span>
|
2023-10-06 20:02:59 +00:00
|
|
|
|
</footer>
|
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
|
|
|
|
</body>
|
|
|
|
|
|
</html>
|
2023-09-11 03:13:57 +00:00
|
|
|
|
|
|
|
|
|
|
{{ define "alternateAnchor" -}}
|
|
|
|
|
|
<a rel="alternate" href="{{ .HRef }}" hreflang="{{ .Lang }}" lang="{{ .Lang }}">{{ .Endonym }}</a>
|
|
|
|
|
|
{{- end }}
|
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
|
|
|
|
|
2023-10-06 20:02:59 +00:00
|
|
|
|
{{ define "companyAddress" -}}
|
|
|
|
|
|
{{- /*gotype: dev.tandem.ws/tandem/camper/pkg/template.address*/ -}}
|
|
|
|
|
|
<address>
|
|
|
|
|
|
{{ .Address }}<br>
|
|
|
|
|
|
{{ .PostalCode}} · {{ .City }} · {{ .Province }}<br>
|
2023-12-20 19:22:32 +00:00
|
|
|
|
{{ .Country }}<br>
|
2023-10-06 20:02:59 +00:00
|
|
|
|
<abbr>T</abbr> <a href="tel:{{ replaceAll .Phone " " "" }}">{{ .Phone }}</a><br>
|
|
|
|
|
|
<a href="mailto:{{ .Email }}">{{ .Email }}</a>
|
|
|
|
|
|
</address>
|
|
|
|
|
|
{{- end }}
|
|
|
|
|
|
|
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
|
|
|
|
{{ define "carouselStyle" -}}
|
|
|
|
|
|
<link rel="stylesheet" media="screen" href="/static/slick@1.8.1.css">
|
|
|
|
|
|
{{- end }}
|
|
|
|
|
|
|
Add home’s cover carousel
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.
2024-01-16 20:05:52 +00:00
|
|
|
|
{{ define "alpineScript" -}}
|
|
|
|
|
|
<script src="/static/alpinejs@3.13.3.min.js" defer></script>
|
|
|
|
|
|
{{- end }}
|
|
|
|
|
|
|
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
|
|
|
|
{{ define "carouselInit" -}}
|
|
|
|
|
|
<script src="/static/jquery@3.7.1.min.js"></script>
|
|
|
|
|
|
<script src="/static/slick@1.8.1.min.js"></script>
|
|
|
|
|
|
<script>
|
|
|
|
|
|
jQuery(function () {
|
|
|
|
|
|
jQuery('.carousel').slick({
|
2024-01-11 20:04:32 +00:00
|
|
|
|
slidesToShow: {{ . }},
|
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
|
|
|
|
slidesToScroll: 1,
|
|
|
|
|
|
infinite: false,
|
|
|
|
|
|
arrows: true,
|
|
|
|
|
|
prevArrow: '<button type="button" class="slick-prev">←</button>',
|
|
|
|
|
|
nextArrow: '<button type="button" class="slick-next">→</button>',
|
|
|
|
|
|
responsive: [
|
2023-12-20 19:11:39 +00:00
|
|
|
|
{
|
|
|
|
|
|
breakpoint: 1024,
|
|
|
|
|
|
settings: {
|
2024-01-11 20:04:32 +00:00
|
|
|
|
slidesToShow: {{ . | dec }},
|
2023-12-20 19:11:39 +00:00
|
|
|
|
}
|
|
|
|
|
|
},
|
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
|
|
|
|
{
|
|
|
|
|
|
breakpoint: 768,
|
|
|
|
|
|
settings: {
|
|
|
|
|
|
slidesToShow: 1,
|
|
|
|
|
|
}
|
|
|
|
|
|
},
|
|
|
|
|
|
]
|
|
|
|
|
|
});
|
|
|
|
|
|
});
|
|
|
|
|
|
</script>
|
|
|
|
|
|
{{- end }}
|
