This is mostly because it is required for the “Digital Kit”, but it also
works in our favor because now i can version the URL to the static
resources.
Go 1.18 adds the info from git if the package is build from a git
repository, but this is not the case in OBS, so i instead relay on a
constant for the version number. This constant is “updated” by Debian’s
rules, mostly due to the discussion in [0].
[0]: https://github.com/golang/go/issues/22706
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
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.
Since campsite types need a media, i have to insert also images to the
media relation. The best would be to use PostgreSQL’s
pg_read_binary_file to read the media content from actual files when
inserting the new rows, but the files need to be within the database
cluster directory, or have to use an absolute path when running as a
superuser to read from files outside the cluster directory, which means
that it would depend on the path where i leave the files, that is
different in development that in staging.
To avoid that problem i can simply insert the rows using their base64
strings, with PostgreSQL’s decode. The images are kind of small, but
i was worried that each change in demo.sql would duplicate that data in
git, even if the change is not related to the images, because git stores
the whole file; even if small, soon everything adds up.
I do not care if the _final_ demo.sql is big, as this file is packaged
in a different deb and is only installed in staging, so i’ve chosen to
use m4 to build a single “amalgamated” SQL file from the base .sql
file and the individual image files converted to base64 strings. That
way, each image is individually managed by git and the base .sql file
does not balloon up for each little change.
Changed m4’s quotes to [[ ]] because the default ` ' was interfering
with Intellij’s syntax highlighting.
Although it is way too soon to install the application on any server,
i use build.opensuse.org as a kind of CI/CD server: it runs the
migration and executes the test suite on each commit. For that, i need
to build *some* package, and Debian suits be better because it has all
the Go packages i use; i would have to create the RPM for many libraries
if i were to use openSUSE, for instance.
According to the de facto project layout for Go[0], these files should
go into a `build/package` folder, but since i already broke the rules
with Sqitch’s folders, i do not see why i have to go against Debian’s
conventions of placing them into a `debian` subfolder of the root.
I have spit the package into the binary and the Sqitch migration files
because it is possible to want the PostgreSQL into a separate server,
and there is little point of having Sqitch and all its dependencies
installed on the front-end server where the Go program runs.
The demo package is probably harder to justify, as it is just a single
file, however i will not run out of packages, will i?
Lintian detects htmx@1.9.3.min.js as a “source-less” file, which is
practically true as nobody is ever going to edit a minified source. I
did not want to include the source in the distribution package, that’s
why i included it in the “missing sources” file, even thought this is a
native debian package and, thus, can not have missing sources.
git-buildpackage creates a lot of extra files that have to be removed
to build it again, otherwise the process detects the new files in the
directory and refuses to build the tarball. I was getting tired of
doing it manually and added a Makefile rule.
Closes#20
jordi fita mas