Skip to main content

Module report

Module report 

Source
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 configuration PARSER uses. So a recipe may render here and fail parse_recipe, or the reverse, and the quantities a template sees are not necessarily the ones recipe::read would 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, so Outcome::diagnostics on the way back is always empty — do not read it as “the recipe was clean”.

Structs§

RenderRequest
A report to render.

Functions§

render
Render req’s recipe through req’s template.