| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
A missing or wrong .Id field for example otherwise results in a silent
error because nothing is actually updated.
|
|
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.
|
|
|
|
The index page / provides a redirect to /recipes but this is inefficient
since two HTTP requests are required.
|
|
|
|
|
|
|
|
|
|
This type is provided to render overview pages easily with a list of all
recipes.
|
|
The new Go type 'Recipe' should contain every information directly
related to a recipe. It should be sufficient to pass it to a template to
directly render a HTML view or edit page for the recipe or to a template
to generate a PDF.
The CRUD methods are:
- func (r *Recipe) Create() error
- func (r *Recipe) Update() error
- func (r *Recipe) Read() error
- func (r *Recipe) Delete() error
Together with the type itself they are the interface the model package
provides for recipes.
|
|
This simple model is used to test if it is helpful to implement the four
CRUD methods create, read, update and delete all inside the model
package.
The model package should also provide the datastructures for these
operations (well suited for the required views) aswell as tests for
them.
With this approach it should be possible to easily implement the view
and controller package because most of the logic is already inside the
model package and is tested.
|
|
This is a simple first HTTP handler and is required to display the
website with the intended design.
|
|
This CSS framework uses nearly only the standard HTML tags and is thus
easy to adopt / replace.
|
|
This adds the infrastructure to add HTTP handlers. It already sets up
the HTTP server and makes sure it is started and stopped.
|
|
This dependency provides a more extended HTTP routing than the Go
standard library.
|
|
This is the intended behaviour for production and also for debugging to
at least inspect the data directory of Ceres.
|
|
This is useful for debugging and testing.
|
|
This provides the basic table structure to the database.
|
|
The already implemented storage folder should contain a sqlite database
to store most parts of the Ceres user data.
|
|
This can be used to implement the `database/sql` interface from the Go
standard library for sqlite databases. This is the currently preferred
method to store user data for Ceres.
|
|
This temporary directory is provided to store the user data for the
Ceres recipe server during development and testing.
|
|
Restarting from scratch seems to be the fastest approach to switch to
sqlite and get rid of some other structural mistakes from the past.
|
|
|
|
This is useful for desktops but is annoying on mobile devices since a
touchscreen keyboard is overlayed automatically and hides half of the
index page.
|
|
|
|
This project does not use the Gemini markup anymore. It was replaced by
JSON.
|
|
|
|
Otherwise this is confusing.
|
|
It is always the same:
- amount float32
- unit string
- type string
This is good as a starting point. Later the types of ingredients might
have to be tracked. In this a string as key is maybe not the best.
|
|
This allows the user to start typing without clicking into the input
field.
|
|
This is way it is way easier to filter recipes by name.
|
|
This is way simpler to handle since you can get a full tarball of Ceres
with everything included which is necessary to run it.
The LICENSE of simple.css allows such a copy and stays inside the copy
to make clear that this folder uses the simple.css license and not the
one of Ceres.
|
|
|
|
Empty title should be avoided because the recipe otherwise just
disappears.
|
|
This removes a lot of repetative code.
|
