Until now i always had the translations be empty strings if some columns
did not have the full translation, but this is going too far on the
non-NULL policy: surely they have a translations, but we do not know it
yet; this is the exact type of situations NULL values are for.
Besides the philosophical distinction, having empty strings instead of
NULLs is less practical, because i no longer can user coalesce() to
retrieve the default language text in case the translation for that
particular field is not available, even if the row for a locale exists.
In time i will change all _i18n relations, but for now only these from
campsite follow the “new policy”.
Otherwise, we can not show the error message to the user, although it
assumes only the default language has error message, which is the case
for now, but….
locale.Translation and form.L10nInput are no longer used.
The translation type in Postgres is now also useless, and i believe it
was never used, but i keep it because I already have a tag and i can not
just remove it, meaning that dropping it is more trouble that worth it.
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.
I want these because when there are changes in the signature i then have
to find where it is used, and it is easier to do when the compiler tells
you.
For relations it is less necessary because GoLand knows how to validate
SQL strings for them, but it seems to not work with functions,
apparently due to the lack of the “FROM” keyword.
Besides, it tx.FunctionName(ctx, params...) is shorter than
tx.Exec("select functions_name($1, $2…)", params...).
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.
This is the first form that uses HTMx, and can not return a 400 error
code because otherwise HTMx does not render the content.
Since now there are pages that do not render the whole html, with header
and body, i need a different layout for these, and moved the common code
to handle forms and such a new template file that both layouts can use.
I also need the request in template.MustRender to check which layout i
should use.
Closes#7.
It is a lot of code having to check the login variables inside the POST
handler, and i could not mark each input field individually as invalid
because the generic errors array i was using did no identify which field
had the error.
Thus, i use more or less the same technique as with Numerus: a struct
with the value and the error message. This time the input field does
not have the label and extra attributes because i believe this belongs
to the template: if i want do reuse the same form template, i should
create a common template rather than defining everything in Go.
The name is a bit different, however, because it has meaning both to the
front and back ends, as it needs to be exactly the same. Writing it
twice is error-prone, as with a rename i could easily forget to change
one or the other, and here i see value in having that in Go, because
it is also used in code.
jordi fita mas