| 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.
|
|
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 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.
|
|
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 unnecessary to call this functionality from main().
|
|
This allows to get the server version via HTTP. The output of `git
describe --dirty --always` and a line break is returned together with
HTTP 200.
If the server build contains no version information an error message and
HTTP 404 is returned.
|
|
This removes the redundant setup of a database/sql.Tx in each HTTP
handler.
|
|
When nesting objects like steps into other objects like recipes it is
required to pass a *sql.Tx value to the CRUD methods of the inner
object to be able to roll back the whole transaction.
The top level object used to be responsible for the creation of this
*sql.Tx inside its CRUD methods.
This is now moved to the caller of the CRUD methods (here the HTTP
handler function). The advantage is that all CRUD methods now accept a
*sql.Tx as only argument which makes those methods more consistent.
|
|
|
|
|
|
|
|
|
|
It should be inside the body tag but used to be before it.
|
|
Design changes should be avoided for now since simple.css cares about
the CSS part of Ceres.
|
|
There is the need to add buttons to the recipe server which act like a
anchor tag (link). This can be achieved by nesting anchor and button
tag.
The problem is that if the user cycles through the elements of the page
with the 'tab' key such a button is handled as two overlapping elements
instead of one.
This commit solves the issue by using buttons with the attribute
`onclick="window.location.href='<url>';`.
|
|
|
|
|
|
They are intended to use multiple lines. This is easier to edit in a
textarea element rather than in an input element.
|
|
|
|
An empty string for one of these attributes will lead to a recipe view
page which does not render the paragraph for this item.
|
|
In the long term the <nav> section at the top should reference the list
views of all managed objects (recipes, users, products and so on).
With this structure it makes more sense to have the button to add a
recipe on the list view on recipes located at /recipes.
|
|
|
|
This allows to cache the involved JavaScript code.
|
|
The <nav> section is the same on every page. This new template reduces
code duplication.
|
|
This makes the update URL more consistent with the other ones. A check
ensures consistency of the URL and JSON ID values.
|
|
|
|
This reflects that these HTTP handler functions implement one of the
four CRUD methods create, read update and delete.
|
|
The old edit URL parameter allowed to select one different HTML
template. A more generic approach is to provide a view parameter which
allows to use multiple alternative HTML templates for the same data
defined by the Go struct.
This makes implementing additional pages like a confirm page for recipe
deletion easier.
|
|
|
|
While forms can be send without JavaScript this new approach has the
benefit that the whole data is send as one JSON.
This JSON format can also be used for an API or testing.
|
|
When a HTML form is converted to JSON by JavaScript using `FormData()`,
`Object.fromEntries()` and `JSON.stringify` the data type is always
`string`. This does not match the Go struct definitions using multiple
types including e.g. `int`.
There are several options to solve this conflict:
1. use only strings in Go struct definitions
2. write custom functions to parse string-based JSONs to Go structs
3. implement custom functions in JS to use `number` type if possible
Option 3 seems to be a very clean solution. Nevertheless it is limited
by the fact that JSON anyway has a way more limited type system than Go.
So the types used in Go cannot be used and this would reduce this option
to a variant of option 2.
Option 2 requires significant effort per struct inside the model
package. Every object which is transferred via JSON and serialized into
Go structs would require a second struct definition with string types
and a conversion function. This does not scale.
Thus option 1 seems to be the best fit. The reasons for using types like
`int` or `bool` are:
- less memory consumption than `string` in most cases
- implicit data validation (e.g. enforcing positive numbers with `uint`)
- better compatibility with certain APIs which rely on e.g. `int`
The first argument is not so relevant in this use case. The amount of
required memory is still quite small for servers. Implicit data
validation is a good thing but not enough. There should anyway be
validation method which has to be called on CRUD methods and JSON
deserialization.
|
|
Otherwise e.g. the Firefox browser throws an error on the console.
|
