2024-02-13 04:20:35 +00:00
|
|
|
HTML_FILES := $(shell find web -name *.gohtml -o -name *.svg -o -name *.gotxt)
|
Add the skeleton of the web application
It does nothing more than to server a single page that does nothing
interesting.
This time i do not use a router. Instead, i am trying out a technique
i have seen in an article[0] that i have tried in other, smaller,
projects and seems to work surprisingly well: it just “cuts off” the
URI path by path, passing the request from handler to handler until
it finds its way to a handler that actually serves the request.
That helps to loosen the coupling between the application and lower
handlers, and makes dependencies explicit, because i need to pass the
locale, company, etc. down instead of storing them in contexts. Let’s
see if i do not regret it on a later date.
I also made a lot more packages that in Numerus. In Numerus i actually
only have the single pkg package, and it works, kind of, but i notice
how i name my methods to avoid clashing instead of using packages for
that. That is, instead of pkg.NewApp i now have app.New.
Initially i thought that Locale should be inside app, but then there was
a circular dependency between app and template. That is why i created a
separate package, but now i am wondering if template should be inside
app too, but then i would have app.MustRenderTemplate instead of
template.MustRender.
The CSS is the most bare-bones file i could write because i am focusing
in markup right now; Oriol will fill in the file once the application is
working.
[0]: https://blog.merovius.de/posts/2017-06-18-how-not-to-use-an-http-router/
2023-07-22 22:11:00 +00:00
|
|
|
GO_FILES := $(shell find . -name *.go)
|
|
|
|
|
DEFAULT_DOMAIN = camper
|
|
|
|
|
POT_FILE = po/$(DEFAULT_DOMAIN).pot
|
2023-12-13 22:55:43 +00:00
|
|
|
LINGUAS = ca es fr
|
Add the skeleton of the web application
It does nothing more than to server a single page that does nothing
interesting.
This time i do not use a router. Instead, i am trying out a technique
i have seen in an article[0] that i have tried in other, smaller,
projects and seems to work surprisingly well: it just “cuts off” the
URI path by path, passing the request from handler to handler until
it finds its way to a handler that actually serves the request.
That helps to loosen the coupling between the application and lower
handlers, and makes dependencies explicit, because i need to pass the
locale, company, etc. down instead of storing them in contexts. Let’s
see if i do not regret it on a later date.
I also made a lot more packages that in Numerus. In Numerus i actually
only have the single pkg package, and it works, kind of, but i notice
how i name my methods to avoid clashing instead of using packages for
that. That is, instead of pkg.NewApp i now have app.New.
Initially i thought that Locale should be inside app, but then there was
a circular dependency between app and template. That is why i created a
separate package, but now i am wondering if template should be inside
app too, but then i would have app.MustRenderTemplate instead of
template.MustRender.
The CSS is the most bare-bones file i could write because i am focusing
in markup right now; Oriol will fill in the file once the application is
working.
[0]: https://blog.merovius.de/posts/2017-06-18-how-not-to-use-an-http-router/
2023-07-22 22:11:00 +00:00
|
|
|
MO_FILES = $(patsubst %,locale/%/LC_MESSAGES/$(DEFAULT_DOMAIN).mo,$(LINGUAS))
|
|
|
|
|
XGETTEXTFLAGS = --no-wrap --from-code=UTF-8 --package-name=camper --msgid-bugs-address=jordi@tandem.blog
|
Add the sample campsite types to the demo file
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.
2023-09-10 01:57:46 +00:00
|
|
|
DEMO_SQL = demo.sql
|
|
|
|
|
|
|
|
|
|
all: locales $(DEMO_SQL)
|
Add the skeleton of the web application
It does nothing more than to server a single page that does nothing
interesting.
This time i do not use a router. Instead, i am trying out a technique
i have seen in an article[0] that i have tried in other, smaller,
projects and seems to work surprisingly well: it just “cuts off” the
URI path by path, passing the request from handler to handler until
it finds its way to a handler that actually serves the request.
That helps to loosen the coupling between the application and lower
handlers, and makes dependencies explicit, because i need to pass the
locale, company, etc. down instead of storing them in contexts. Let’s
see if i do not regret it on a later date.
I also made a lot more packages that in Numerus. In Numerus i actually
only have the single pkg package, and it works, kind of, but i notice
how i name my methods to avoid clashing instead of using packages for
that. That is, instead of pkg.NewApp i now have app.New.
Initially i thought that Locale should be inside app, but then there was
a circular dependency between app and template. That is why i created a
separate package, but now i am wondering if template should be inside
app too, but then i would have app.MustRenderTemplate instead of
template.MustRender.
The CSS is the most bare-bones file i could write because i am focusing
in markup right now; Oriol will fill in the file once the application is
working.
[0]: https://blog.merovius.de/posts/2017-06-18-how-not-to-use-an-http-router/
2023-07-22 22:11:00 +00:00
|
|
|
|
|
|
|
|
locales: $(MO_FILES)
|
|
|
|
|
|
|
|
|
|
locale/%/LC_MESSAGES/camper.mo: po/%.po
|
|
|
|
|
mkdir -p $(@D)
|
|
|
|
|
msgfmt -o $@ $<
|
|
|
|
|
|
|
|
|
|
po/%.po: $(POT_FILE)
|
|
|
|
|
msgmerge --no-wrap --update --backup=off $@ $<
|
|
|
|
|
|
|
|
|
|
$(POT_FILE): $(HTML_FILES) $(GO_FILES)
|
|
|
|
|
xgettext $(XGETTEXTFLAGS) --language=Scheme --output=$@ --keyword=pgettext:1,2c $(HTML_FILES)
|
Manage all media uploads in a single place
It made no sense to have a file upload in each form that needs a media,
because to reuse an existing media users would need to upload the exact
same file again; this is very unusual and unfriendly.
A better option is to have a “centralized” media section, where people
can upload files there, and then have a picker to select from there.
Ideally, there would be an upload option in the picker, but i did not
add it yet.
I’ve split the content from the media because i want users to have the
option to update a media, for instance when they need to upload a
reduced or cropped version of the same photo, without an edit they would
need to upload the file as a new media and then update all places where
the old version was used. And i did not want to trouble people that
uploads the same photo twice: without the separate relation, doing so
would throw a constraint error.
I do not believe there is any security problem to have all companies
link their media to the same file, as they were already readable by
everyone and could upload the data from a different company to their
own; in other words, it is not worse than it was now.
2023-09-20 23:56:44 +00:00
|
|
|
xgettext $(XGETTEXTFLAGS) --language=C --output=$@ --keyword=Gettext:1 --keyword=GettextNoop:1 --keyword=Pgettext:1,2c --keyword=PgettextNoop:1,2c --join-existing $(GO_FILES)
|
Add the skeleton of the web application
It does nothing more than to server a single page that does nothing
interesting.
This time i do not use a router. Instead, i am trying out a technique
i have seen in an article[0] that i have tried in other, smaller,
projects and seems to work surprisingly well: it just “cuts off” the
URI path by path, passing the request from handler to handler until
it finds its way to a handler that actually serves the request.
That helps to loosen the coupling between the application and lower
handlers, and makes dependencies explicit, because i need to pass the
locale, company, etc. down instead of storing them in contexts. Let’s
see if i do not regret it on a later date.
I also made a lot more packages that in Numerus. In Numerus i actually
only have the single pkg package, and it works, kind of, but i notice
how i name my methods to avoid clashing instead of using packages for
that. That is, instead of pkg.NewApp i now have app.New.
Initially i thought that Locale should be inside app, but then there was
a circular dependency between app and template. That is why i created a
separate package, but now i am wondering if template should be inside
app too, but then i would have app.MustRenderTemplate instead of
template.MustRender.
The CSS is the most bare-bones file i could write because i am focusing
in markup right now; Oriol will fill in the file once the application is
working.
[0]: https://blog.merovius.de/posts/2017-06-18-how-not-to-use-an-http-router/
2023-07-22 22:11:00 +00:00
|
|
|
|
2023-07-22 21:56:16 +00:00
|
|
|
test-deploy:
|
|
|
|
|
sqitch deploy --db-name $(PGDATABASE)
|
|
|
|
|
pg_prove test/*
|
|
|
|
|
|
Add the sample campsite types to the demo file
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.
2023-09-10 01:57:46 +00:00
|
|
|
$(DEMO_SQL): demo/demo.sql demo/plots.avif demo/safari_tents.avif demo/bungalows.avif demo/wooden_lodges.avif
|
|
|
|
|
m4 --prefix-builtins $< > $@
|
|
|
|
|
|
Add Debian package
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
2023-07-27 17:20:29 +00:00
|
|
|
clean:
|
Add the sample campsite types to the demo file
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.
2023-09-10 01:57:46 +00:00
|
|
|
$(RM) $(DEMO_SQL)
|
Add Debian package
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
2023-07-27 17:20:29 +00:00
|
|
|
$(RM) $(MO_FILES)
|
|
|
|
|
$(RM) $(POT_FILE)
|
|
|
|
|
$(RM) debian/debhelper-build-stamp
|
|
|
|
|
$(RM) debian/camper-demo.substvars
|
|
|
|
|
$(RM) debian/camper-sqitch.substvars
|
|
|
|
|
$(RM) debian/camper.postrm.debhelper
|
|
|
|
|
$(RM) debian/camper.substvars
|
|
|
|
|
$(RM) debian/files
|
|
|
|
|
$(RM) debian/golang-tandem-camper-dev.substvars
|
|
|
|
|
$(RM) -r _build/
|
|
|
|
|
$(RM) -r debian/.debhelper/
|
|
|
|
|
$(RM) -r debian/camper/
|
|
|
|
|
$(RM) -r debian/golang-tandem-camper-dev/
|
|
|
|
|
$(RM) -r debian/tmp/
|
|
|
|
|
$(RM) -r debian/camper-demo/
|
|
|
|
|
$(RM) -r debian/camper-sqitch/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.PHONY: locales test-db clean
|