| Age | Commit message (Collapse) | Author |
|---|
|
This follows the process described in RELEASE.md to make sure the
development versions are not mixed up with the released ones.
|
|
|
|
|
|
The changelog should be changed before updating the version to make sure
changing the version is the commit which is tagged.
Furthermore there was a mistake that the suffix `-devel` should be
removed after release. Instead it should be added.
|
|
This contained an unwanted newline.
|
|
This marks favorite recipes with a `⭐` emoticon. The favorite flag
value can be set on the recipe edit page. Favorite recipes are listed
first on the recipe list view.
Furthermore as a second priority the created time stamp is used in the
recipe list so that more recent recipes are listed first.
|
|
This adds the ability to store a flag `is_favorite` inside the database.
The corresponding SQL migration is part of this commit.
Furthermore the Go code in the model package is adapted.
|
|
This makes it easier for humans and software to detect that this is a
plain text file.
|
|
This makes the recipe page less pretty. Nevertheless the URL is more
visible to the user which makes it more likely that errors in the URL
are detected.
This change is based on user feedback. Invalid URLs were added which led
effectively to data loss.
|
|
This makes it easier to write a shopping list for the required
ingredients.
|
|
The functions in the sub-packages model, view and controller should not
log too much. Instead they should return errors which can be extended by
fmt.Errorf("<some mesage>: %w", err).
|
|
The used `func(http.ResponseWriter, *http.Request)` return values made
the HTTP handler factory functions quite unreadable. Thus it is switched
to the http.Handler type.
|
|
|
|
API changes were not adopted in the unit tests.
|
|
|
|
|
|
This drops the build dependency GNU Make. The resulting build steps are
typical for Go repositories and thus more familiar for Go developers.
|
|
The build flags made the basic build and debug calls quite complex and
bound this strictly to Git repositories which is a problem if the source
code is passed around as tar archive.
Embedding this via Go's embed package and a VERSION.txt file makes this
way easier. A simple `go build` command is sufficient to build ceres.
To make sure the version string is extended by a `-devel` marker and
that this marker is removed before a release a RELEASE.md file was added
as a checklist for releases.
|
|
The reason for the introduction of this dependency was that it was easy
to setup routes with HTTP method restrictions.
Since Go 1.22 this feature is part of the standard library. Method
restrictions are part of the patterns used to register routes [1].
[1]: https://pkg.go.dev/net/http#hdr-Patterns-ServeMux
|
|
This option for the go tool activates a race condition detector. It
makes building the executable slower. Nevertheless it is worth it since
it detects a lot of race conditions and race conditions should be
avoided as much as possible.
|
|
|
|
The old name database.go did not match the type name DB.
|
|
This commit makes not externally needed methods private and adds error
return values since something like log.Fatal() should be called outside
this package since it is control-flow-related.
|
|
Ceres v0.4.0 used the `git describe` output as database schema and
enforced exactly matching versions between the database and the
executable.
This turned out to be not flexible enough. It is way easier to version
the database separately with a simple integer and require the same
database schema version integer between the application and the
database.
This commit implements this new approach.
|
|
This references the database schemas known from the past with integer
values internally. 0 is used for an empty database and 1 for what was
used in ceres version 0.4.0.
The old approach to write the `git describe` output into the database
worked well for released versions but was problematic during
development. A numerical and separate database schema versioning is
easier to handle.
|
|
|
|
It is not required to create a struct definition with only one member.
The new solution is more elegant.
|
|
Reducing global variables makes it easier to understand functions
independently of the rest of the code.
Adding the new model.DB type as a custom variant of the sql.DB type
makes it possible to write methods for the database which makes the code
way more readable.
|
|
This new package is only for database migrations. All data for Ceres
should be stored inside the SQLite3 database. Thus migrations can always
be executed with functions with the following signature.
func(tx *sql.Tx) error
Those migration functions should be stored inside the new package.
Bigger SQL code can be stored in *.sql files for better syntax
highlighting. This code is embedded into the final Go executable by
using the embed package.
|
|
Instead a database transaction has to be used. Each database interaction
should be wrapped into a transaction to make sure any possible change
(even side-effects) can be rolled back in case of errors.
|
|
This script should contain any validation routines for the source code.
Creating a symlink to it from .git/hooks/pre-commit for pre-commit
validation might be a use case.
In this initial version only the `go fmt` call is added to apply
automated Go code formatting.
|
|
This applies default Go code style recommendations.
|
|
|
|
|
|
|
|
This could also lead to bugs.
|
|
An ignored return value here caused a serious bug as soon as validation
for ingredients was tried. The validation could raise an error e.g. on a
negative amount for the ingredient. This error was ignored at the
changed line which resulted into deleted ingredients for the whole
recipe.
|
|
This reduces code duplication and enforces time stamps.
|
|
The recipe edit page HTML template did not contain the two time stamps
"Created" and "LastChanged" as hidden form values.
Thus the information was not passed from the backend to the frontend. On
a save the recipe without time stamp information was injected into the
backend.
This effectively deleted any time stamp information. This commit fixes
that bug by including all fields of the model.Recipe struct inside the
form of the recipe-edit.html template.
|
|
This accepts only real numbers with a minimum step of 0.001 as input for
the amount field of a recipe ingredient.
The browser has the chance to give the user direct feedback that a
non-numeric string will not work.
|
|
If the recipe has no ingredients at all the "Ingredient summary:" text
used to be displayed. This is not useful and confusing. It is removed
with this commit.
|
|
Before the next release this method should be as strict as possible to
avoid cases where actually invalid enters databases.
|
|
It does not make sense to add empty steps.
|
|
It does make sense to add an ingredient only with a type and no amount
or unit like 'salt'. But it does not make sense to add an ingredient
without a type like '5' or '2 l'.
|
|
This is the latest available release. Updated to keep up to date and
adopt fixes.
|
|
This used to be named 'Ingredients: which might be confusing since
ingredients are defined per step and the list at the top of the recipe
is just a summary.
|
|
the first text input of that new element.
This supports using Ceres without a mouse and only with tab-based
navigation with a keyboard.
|
|
|
|
|
|
|
