tandem/camper
tandem
/
camper
2
0
Fork 0
Code Issues 7 Pull Requests Packages Projects Releases Wiki Activity
camper/web/templates/admin/home/index.gohtml

128 lines
5.2 KiB
Plaintext
Raw Normal View History

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
<!--
SPDX-FileCopyrightText: 2023 jordi fita mas <jordi@tandem.blog>
SPDX-License-Identifier: AGPL-3.0-only
-->
{{ define "title" -}}
{{( pgettext "Home Page" "title" )}}
{{- end }}
Add breadcrumb to all admin pages 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.
2024-01-21 21:44:04 +00:00
{{ define "breadcrumb" -}}
{{- end }}
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
{{ define "content" -}}
{{- /*gotype: dev.tandem.ws/tandem/camper/pkg/home.homeIndex*/ -}}
Make the slogan user-editable and translatable Because God forbid we have any performance; everything —**everything**— must be user editable.
2024-01-23 10:52:39 +00:00
{{ with .Form }}
<h2>{{( pgettext "Slogan" "title")}}</h2>
<form data-hx-put="/admin/home">
{{ CSRFInput }}
<fieldset {{ template "init-lang" . }}>
{{ with .Slogan -}}
<fieldset>
<legend>{{( pgettext "Slogan" "input")}}</legend>
{{ template "lang-selector" . }}
{{ range $lang, $input := . -}}
<label x-cloak x-show="lang === '{{ $lang }}'"><span>{{ $lang }}</span><br>
<input type="text" name="{{ $input.Name }}" value="{{ $input.Val }}"
{{ template "error-attrs" . }}><br>
</label>
{{- end }}
{{ template "error-message" . }}
</fieldset>
{{- end }}
</fieldset>
<footer>
<button type="submit">{{( pgettext "Update" "action" )}}</button>
</footer>
</form>
{{- 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
<h2>{{( pgettext "Cover" "title" )}}</h2>
<a href="/admin/home/cover/new">{{( pgettext "Add cover image" "action" )}}</a>
{{ if .Cover -}}
<form id="slide-index"
class="sortable"
data-hx-post="/admin/home/cover/order"
data-hx-trigger="end"
data-hx-select="#slide-index"
data-hx-swap="outerHTML"
>
{{ CSRFInput }}
<table>
<thead>
<tr>
<th scope="col">{{( pgettext "Image" "header" )}}</th>
<th scope="col">{{( pgettext "Caption" "header" )}}</th>
<th scope="col">{{( pgettext "Actions" "header" )}}</th>
</tr>
</thead>
<tbody>
{{ $confirm := (gettext "Are you sure you wish to delete this cover image?")}}
{{ range $slide := .Cover -}}
<tr>
<td>
<span class="handle"></span>
<input type="hidden" name="media_id" value="{{ .ID }}">
<a href="/admin/home/cover/{{ .ID }}"><img src="{{ .Media }}" alt=""></a>
</td>
<td><a href="/admin/home/cover/{{ .ID }}">{{ .Caption }}</a></td>
<td>
<button data-hx-delete="/admin/home/cover/{{ .ID }}"
data-hx-confirm="{{ $confirm }}"
data-hx-headers='{ {{ CSRFHeader }} }'>
{{( pgettext "Delete" "action" )}}
</button>
</td>
</tr>
{{- end }}
</tbody>
</table>
</form>
{{ else -}}
<p>{{( gettext "No images added to the cover yet." )}}</p>
{{- end }}
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
<h2>{{( pgettext "Carousel" "title" )}}</h2>
<a href="/admin/home/slides/new">{{( pgettext "Add slide" "action" )}}</a>
{{ if .Slides -}}
Add user-defined order to campsite types, options, seasons and carousels I use Sortable, exactly like HTMx’s sorting example does[0]. Had to export the slug or ID of some entries to be able to add it in the hidden input. For forms that use ID instead of slug, had to use an input name other than “id” because otherwise the swap would fail due to bug #1496[1]. It is apparently fixed in a recent version of HTMx, but i did not want to update for fear of behaviour changes. [0]: https://htmx.org/examples/sortable/ [1]: https://github.com/bigskysoftware/htmx/issues/1496
2023-12-20 18:52:14 +00:00
<form id="slide-index"
class="sortable"
data-hx-post="/admin/home/slides/order"
data-hx-trigger="end"
data-hx-select="#slide-index"
data-hx-swap="outerHTML"
>
{{ CSRFInput }}
<table>
<thead>
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
<tr>
Add user-defined order to campsite types, options, seasons and carousels I use Sortable, exactly like HTMx’s sorting example does[0]. Had to export the slug or ID of some entries to be able to add it in the hidden input. For forms that use ID instead of slug, had to use an input name other than “id” because otherwise the swap would fail due to bug #1496[1]. It is apparently fixed in a recent version of HTMx, but i did not want to update for fear of behaviour changes. [0]: https://htmx.org/examples/sortable/ [1]: https://github.com/bigskysoftware/htmx/issues/1496
2023-12-20 18:52:14 +00:00
<th scope="col">{{( pgettext "Image" "header" )}}</th>
<th scope="col">{{( pgettext "Caption" "header" )}}</th>
<th scope="col">{{( pgettext "Actions" "header" )}}</th>
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
</tr>
Add user-defined order to campsite types, options, seasons and carousels I use Sortable, exactly like HTMx’s sorting example does[0]. Had to export the slug or ID of some entries to be able to add it in the hidden input. For forms that use ID instead of slug, had to use an input name other than “id” because otherwise the swap would fail due to bug #1496[1]. It is apparently fixed in a recent version of HTMx, but i did not want to update for fear of behaviour changes. [0]: https://htmx.org/examples/sortable/ [1]: https://github.com/bigskysoftware/htmx/issues/1496
2023-12-20 18:52:14 +00:00
</thead>
<tbody>
{{ $confirm := (gettext "Are you sure you wish to delete this slide?")}}
{{ range $slide := .Slides -}}
<tr>
<td>
<span class="handle"></span>
<input type="hidden" name="media_id" value="{{ .ID }}">
<a href="/admin/home/slides/{{ .ID }}"><img src="{{ .Media }}" alt=""></a>
</td>
<td><a href="/admin/home/slides/{{ .ID }}">{{ .Caption }}</a></td>
<td>
Avoid nested forms in admin 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.
2024-01-16 17:32:02 +00:00
<button data-hx-delete="/admin/home/slides/{{ .ID }}"
data-hx-confirm="{{ $confirm }}"
data-hx-headers='{ {{ CSRFHeader }} }'>
{{( pgettext "Delete" "action" )}}
</button>
Add user-defined order to campsite types, options, seasons and carousels I use Sortable, exactly like HTMx’s sorting example does[0]. Had to export the slug or ID of some entries to be able to add it in the hidden input. For forms that use ID instead of slug, had to use an input name other than “id” because otherwise the swap would fail due to bug #1496[1]. It is apparently fixed in a recent version of HTMx, but i did not want to update for fear of behaviour changes. [0]: https://htmx.org/examples/sortable/ [1]: https://github.com/bigskysoftware/htmx/issues/1496
2023-12-20 18:52:14 +00:00
</td>
</tr>
{{- end }}
</tbody>
</table>
</form>
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
{{ else -}}
<p>{{( gettext "No slides added yet." )}}</p>
{{- end }}
{{- end }}