| Age | Commit message (Collapse) | Author |
|---|
|
This is expected functionality for a command line application.
|
|
This allows to formulate the test data with an object-based model which
is easier than writing it down in a relational model.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Otherwise e.g. the Firefox browser throws an error on the console.
|
|
|
|
|
|
|
|
This is a simple first HTTP handler and is required to display the
website with the intended design.
|
|
This adds the infrastructure to add HTTP handlers. It already sets up
the HTTP server and makes sure it is started and stopped.
|
|
This is the intended behaviour for production and also for debugging to
at least inspect the data directory of Ceres.
|
|
The already implemented storage folder should contain a sqlite database
to store most parts of the Ceres user data.
|
|
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.
|
|
That way only the system user setup and ownership change has to be done
by the packager / installer.
|
|
Using a database is way more complex (see the commit statistics of this
commit) than using files to store recipe data. Also administration and
usage is simpler.
|
|
This makes templating easier and allows to use partial templates.
|
|
This auto-applies the recommended Go codestyle.
|
|
This has nothing to do with the database. Because the db is now a global
pointer the shutdown code can live in main.go.
|
|
Logging during a request is at the moment not really needed. Printing
the config to the log was a stupid idea too.
|
|
Passing the database pointer around is a lot of text and has no benefit.
|
|
|
|
|
|
|
|
Passing the config completly or just partial around via function
arguments creates a lot of noice and does not have benefits.
The only downside is that it is possible to write the config after
initialization but it is realistic that this can be avoided.
|
|
|
|
This project is not so big that it needs multiple packages.
|
|
This repository is just about the generic source code. Adapting it to a
certain Linux distribution which might be systemd based is up to a
packaging repository.
|
|
|
