Make Context use StaticRegisters by default. This makes it easier to
ensure that all subcontexts share the same static registers.
Co-authored-by: Dylan Thacker-Smith <[email protected]>
Liquid::Context#squash_instance_assigns_with_environments can result in
Proc objects in the environment to be eagerly evaluated. So it should be
possible to finish initializing the context object before this is done.
Allowing a block to be used for this purpose avoids the need to add
additional parameters for this purpose.
Example:
```
// the_count.liquid
{{ number }}! Ah ah ah.
// my_template.liquid
{% for number in range (1..3) %}
{% render "the_count", number: number %}
{% endfor %}
Output:
1! Ah ah ah.
2! Ah ah ah.
3! Ah ah ah.
```
The `render` tag is a more strict version of the `include` tag. It is
designed to isolate itself from the parent rendering context both by
creating a new scope (which does not inherit the parent scope) and by
only inheriting "static" registers.
Static registers are those that do not hold mutable state which could
affect rendering. This again helps `render`ed templates remain entirely
separate from their calling context.
Unlike `include`, `render` does not permit specifying the target
template using a variable, only a string literal. For example, this
means that `{% render my_dynamic_template %}` is invalid syntax. This
will make it possible to statically analyze the dependencies between
templates without making Turing angry.
Note that the `static_environment` of a rendered template is inherited, unlike
the scope and regular environment. This environment is immutable from within the
template.
An alternate syntax, which mimics the `{% include ... for %}` tag is
currently in design discussion.
An isolated subcontext inherits the environment, filters,
and static registers of its supercontext, but with a fresh
(isolated) scope.
This will pave the way for adding the `render` tag, which renders
templates in such a subcontext.
This could be used to preserve the old default of rendering
non-Liquid::Error messages or for providing default behaviour like error
reporting which could be missed if the exception renderer needed to be
specified on each render.
These errors may contain sensitive information, so is safer to
render a more vague message by default.
This is done by replacing non-Liquid::Error exceptions with a
Liquid::InternalError exception with the non-Liquid::Error accessible on
through the cause method. This also allows the template name and line
number to be attached to the template errors.
The exception_handler render option has been changed to exception_renderer
since now it should raise an exception to re-raise on a liquid rendering
error or return a string to be rendered where the error occurred.
Although the author of the liquid template wants to see these errors, they
probably don't want the visitor to see the liquid errors. Probably the
best fallback when rendering the page for visitors is to render the empty
string for tags with errors.
Michael Go