| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
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.
|
|
Without verification the text input is simply saved to the file. This is
no problem for the recipe editing but since the json.Unmarshal functino
will also fail on the index and recipe page this recipe will simply
disappear from the web server while the file still exists on disk.
|
|
This is actually possible when using <textarea> instead of <pre>. With
this change the recipe server has full support for browsers without
JavaScript.
|
|
|
|
This reduces the number of clicks to delete a recipe.
|
|
|
|
|
|
|
|
Markup parsing is not needed anymore since recipes are now modeled as
JSON text.
|
|
|
|
|
|
Using spaces removes the need to care about the tabwidth of different
browsers.
|
|
|
|
|
|
|
|
That way only the system user setup and ownership change has to be done
by the packager / installer.
|
|
This is up to the packager. Inside that data directory the application
is allowed to create folders on its own.
|
|
There were some templates missing.
|
|
This is useful for the case that no recipes exist or the recipe data
folder does not exist.
|
|
The only left entry was `vendor` which was used to save Go dependencies.
Since there are no dependencies anymore this file is removed.
|
