| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
The security advice cares about HTML injected from recipe markup into
HTML templates. This is not a considered threat because the user is
trusted in this earlx version.
|
|
If no title is detected, a default text should be inserted instead. This
avoids not clickable links on the index page.
|
|
This was not fully implemented and looks better as normal text line than
as <pre> element.
|
|
|
|
This is now just not needed.
|
|
This shows some more markup features / edge cases.
|
|
The new custom and text/gemini inspired markup has to be converted to
HTML to display the recipe.
|
|
The gemini protocol specification includes a section about the
text/gemini MIME type. This file format is a easy to parse markup
language which should be used for the Ceres recipe server.
|
|
The new recipe markup which replaces Markdown will need an own file to
be implemented.
|
|
This step prepares moving to a new, custom and easily parsable markup
language.
|
|
|
|
|
|
|
|
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 prepares the switch to a file-based store of recipe data replacing
MariaDB.
|
|
|
|
|
|
|
|
The upstream URL can be encoded easily by the user in the Markdown-based
description. The title can be parsed by the first found top-level
heading in the Markdown text.
Thus these two columns are no longer used. To avoid an additional
migration they will be kept in the database.
|
|
Recipe images are currently complicated to implement and have little
use. Probably they will not be covered in the next release.
|
|
Since there are no good solutions to upload the file and markdown
description text via HTML forms the edit page will upload the changes
using embedded javascript.
The page is now complete apart from the necessary javascript code and
the backend handlers.
|
|
|
|
This allows to use partial HTML files via Go's templating features.
|
|
|
|
This reduces copies of the same HTML code.
|
|
This makes templating easier and allows to use partial templates.
|
|
Docstrings for functions are a good thing. But the inside of a function
should be written in a way that is self-explaining. Thus inline comments
are just extra stuff to maintain and read.
|
|
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.
|
