| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This makes the JS function way simpler and removes a duplication of the
step HTML code.
|
|
This allows to use it in two places:
- template for loop for backend-generated steps
- a HTML template tag for frontend- / JS-generated steps
|
|
|
|
This makes it impossible to move the whole JS functionality into the
central ceres.js script. Moving that JS code there makes caching
possible and bundles all JS-related code in one file.
The overall goal is to get rid of as many JS code as possible.
|
|
This is metadata about the config and thus does not belong to the config
itself. Moving it to the struct holding flag values is straight forward
since it is defined by flags.
|
|
|
|
|
|
The default use case should be to not inject example recipes.
|
|
|
|
This makes the code easier to understand because there is an executable
version and a database version handled inside that file.
|
|
|
|
Currently only an empty database and an existing database with the same
version are supported.
Support for migrations based on semantic versioning will be added in
future versions of Ceres.
|
|
|
|
If the database was empty on startup a metadata table with a key and
value row is created.
In addition the Ceres executable version is inserted as value under the
key 'version'.
This allows to detect on not-empty databases which Ceres version was
used before which is the starting point to implement migrations.
|
|
An empty database requires to add the metadata table with the version
entry to make migrations possible. Thus this detection will be required.
|
|
This makes it more clear that the full migration will be rolled back on
errors.
|
|
|
|
This takes up way less space in the code and the actual user view.
|
|
To avoid not clickable recipes on the /recipes page a default name used
to be inserted on recipe creation.
This was not a proper fix for the problem and also was annoying that the
user first had to remove the default recipe name.
This commit removes this default name.
|
|
In addition to the enforcement of titles in the model package the HTML
form field for the title is set to 'required' to give the user feedback
via the browser that a title is required.
|
|
If a recipe has no title it is hard to reference in the front end.
Especially the /recipes page makes problems in that case since it is
impossible to click on that recipes and thus also to remove it.
|
|
A committed transaction cannot be rolled back. Using defer to roll back
guarantees that the transaction is always rolled back if not the commit
in the last line of model.Transaction was excuted.
[1]: https://go.dev/doc/database/execute-transactions
|
|
|
|
It is a very common pattern that some function needs to access the
database and wants to wrap all the actions into one transaction.
The advantage of a transaction is that it is ACID:
- atomic
- consistent
- isolated
- durable
In Go it is required to request a new transaction, execute functionality
on it and handle rollback or commit of this transaction based on the
success of the operation.
All this and the error handling can be written down in the
model.Transaction() function exactly once. The full signature of it is:
func Transaction(f func(*sql.Tx) error) error
It requires a function or closure passed as argument which takes the
transaction (*sql.Tx) and returns an error which might be nil.
This is very generic. It is applied to:
- injecting test data
- database migrations
- data read requests
- data write requests
|
|
This makes it easier to run unit tests.
|
|
|
|
This variable will be the only used representation for version
information. It can trivially be used for an equality check. Further
data as semantic versioning must be parsed from this string.
|
|
This improves readability of the main() function.
|
|
This makes it unnecessary to call this functionality from main().
|
|
|
|
This separates the main control flow and HTTP-related high-level code.
Furthermore the new main.Server type makes the related methods and
function more like the functions from the standard library with a
NewServer() function and methods with only one word as name.
|
|
The intention of this file was that a Ceres executable could compare its
version with the version of the storage folder.
If the versions match the storage folder could be directly used. If the
storage version is lower the executable can apply migrations to the
storage folder until the versions match.
The problem is that executing migrations inside the database and
updating the version.txt cannot be atomic.
In contrast the version string could be saved inside the database itself
in a metadata table. In that case the migration together with the update
of the version string can be executed inside one database transaction
which guarantees atomicity.
The problem could still be that migrations should be applied also to the
files and folders inside the storage folder. This problem can only be
avoided by not using files to store data and instead use the BLOB
datatype if necessary.
Even in case of a future filesystem use it is still better to have the
guarantee that the database with file paths and metadata and the there
included version string are in sync.
|
|
It is a common pattern inside the Go standard library to provide a
constructor with this naming scheme to custom types of the package.
Doing this here results in a style closer to the standard library which
improves readability.
|
|
The model package where this used to be implemented should not care too
much about logging. Furthermore it is easier to compare the log output
with the main() function if the log statements are there.
|
|
This makes it easier to read the logs and follows the pattern to move
log messages more to the main() function instead of spreading them
accross the whole code base.
|
