Struct HumusEngine

Source

pub struct HumusEngine<V, S, F>where
    V: HumusView<S, F>,
    S: HumusQuerySettings<F>,
    F: HumusFormat,{
    pub tera: Tera,
    pub template_config: Option<Table>,
    /* private fields */
}

Available on crate feature axum-view only.

Expand description

🌄 Tera based Templating Engine that writes out axum Response structs.

The engine uses logic and data from the configured View (V) type as well as data and configuration provided by the QuerySettings (S) type to produce the desired response with minimal code overhead inside your main logic.

Note: The private fields are PhantomData because the V, S and N generics are only used for the implementation.

The Engine operates in one of two modes determined by the Format (F) which is provided by the QuerySettings:

Template Mode: The Format describes which template to use for rendering the View to some kind of text using Tera templates.
API Mode: The View serializes itself, usually to a Json Response.

§Template Mode

In template mode the following sequence of events happens:

status code, format and cookies are fetched. (The cookie functionality is enabled with the axum-view+cookie feature)
Template name and MimeType are fetched.
The Template context is populated with metadatam the View and template_config.
The QuerySettings are given the chance to populate the context with their own values using the initalize_template_context() hook.
The template gets rendered, resulting in further processing or an error response.
The response is constructed using the MimeType from earlier and the text from the template.
The View is given a chance to alter the Response using the update_response() hook.
If the status code of the Response is “200 OK” (the default) the status code and cookies fetched earlier are applied.

§Template Symbols

The symbols defined for inside templates are:

view will contain the template name, that coincides with the basename of the template file.
format will contain the format name (i.e. html, text, json)
mime_type will contain the serialized mime_type (i.e. text/plain; charset=utf-8 or application/json)
http_status will contain the numeric HTTP status code.
data will contain the serde serialized View
extra will be set to template_config which usually comes from an extra.toml file in the template directory or a configured custom location.
others that were added by the QuerySettings in initalize_template_context()

§API Mode

In API mode the following, simpler sequence of events happens:

status code, format and cookies are fetched. (The cookie functionality is enabled with the axum-view+cookie feature)
The View serializes itself using the get_api_response() callback.
If the status code of the Response is “200 OK” (the default) the status code and cookies fetched earlier are applied.

Fields§

§tera: Tera

An instance of the tera templating engine.

§template_config: Option<Table>

If it was possible to read any extra configuration it will be stored here.

Implementations§

Source §

impl<V, S, F> HumusEngine<V, S, F>
where V: HumusView<S, F>, S: HumusQuerySettings<F>, F: HumusFormat,

Source

pub fn new(tera: Tera, template_config: Option<Table>) -> Self

Creates a new Templating Engine.

An alternative would be converting from a HumusProtoEngine.

Source

pub fn render_view(&self, settings: &S, view: V) -> Response

Takes settings and a view, converting it to a serveable response.

Example:

async fn hello_world_handler(
	State(arc_state): State<Arc<ServiceSharedState>>,
	Extension(settings): Extension<QuerySettings>,
) -> Response {
	let state = Arc::clone(&arc_state);

	state.templating_engine.render_view(
		&settings,
		View::Message{
			title: "Hey There!".to_string(),
			message: "You are an awesome creature!".to_string()
		},
	)
}