Expand description
Rendering a recipe through a Jinja2 template.
render is a thin, non-fatal layer over the cooklang-reports crate: it
resolves the recipe and the aisle/pantry configuration the way the rest of
this crate does, hands the result to cooklang-reports, and turns any
failure into a CoreError instead of ending the process.
§What a template can see
The variables come from cooklang-reports, not from here. As of 0.5.1 they
are scale, sections, ingredients, cookware, metadata, datastore,
base_path, aisle_content and pantry_content, plus the functions and
filters that crate registers — db, get_ingredient_list, aisled,
excluding_pantry, from_pantry, the number_* family and the string
filters. There is no recipe variable: {{ recipe.title }} is
{{ metadata.title }}, and recipe.ingredients is ingredients.
§Two things cooklang-reports does that this crate cannot stop
- It parses the recipe itself, with
CooklangParser::canonical(every extension on, no unit converter) rather than the configurationPARSERuses. So a recipe may render here and failparse_recipe, or the reverse, and the quantities a template sees are not necessarily the onesrecipe::readwould produce. - It writes warnings straight to stderr. Recipe warnings, aisle and
pantry warnings, and a datastore key it could not find are all
eprintln!ed from inside the render call. Nothing reaches this crate, soOutcome::diagnosticson the way back is always empty — do not read it as “the recipe was clean”.
Structs§
- Render
Request - A report to render.
Functions§
- render
- Render
req’s recipe throughreq’s template.