| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
