Update render and render_basic methods on Block to take a context kwarg
Update TableBlock to support passing extra context to render
Implement render_as_block on BoundBlock, StreamValue and StructValue.
Collectively, these are the objects encountered during template rendering which typically render
a block template when output inside {{ ... }} tags. Implementing render_as_block allows us to do
the same thing, but passing a template context as well.
Implement include_block tag
Support extra context vars on include_block via 'with foo=bar'
Support 'only' flag on include_block tag, to omit the parent context
Update StreamField documentation to cover the include_block tag
Rewrite 'BoundBlocks and values' docs based on the include_block tag
Add tests for blocks with legacy render / render_basic methods
Any bits of StreamField infrastructure that attempt to call render or render_basic
on a block with a 'context' kwarg, should (for now) also work on blocks that don't
accept the context kwarg, but output a RemovedInWagtail18Warning.
Explicitly test whether render / render_basic will accept a 'context' kwarg
This avoids unexpected behaviour when the method legitimately accepts a context
kwarg, but happens to throw an unrelated TypeError - in this situation, the final
output (or error diagnostics) will behave as if the context was never passed,
making debugging difficult. See https://github.com/torchbox/wagtail/pull/2786#discussion_r69563984
The `form_template` attribute was mentioned in passing in the docs, but was missing various things
to make it fully useful:
- context passed to form_template now includes 'prefix' and 'block_definition'
- context for the form is now populated in a separate overrideable `get_form_context` method
- full documentation and tests for form_template and get_form_context added
The individual `error_message` kwarg on RegexField is deprecated in Django 1.8
(and removed in Django 1.10), so it's appropriate for RegexBlock to follow the
same convention.
Most of the samples were already 4-space indented, but a few were using 2-space,
which is both inconsistent and, when it happened with Python code samples,
incompatible with PEP8.
All `.. code::` instances have been changed to use `.. code-block::`,
and have been properly formatted. The syntax names have been normalised,
so all django templates use the `html+django` syntax, shell commands use
`sh`, and plain text uses `text`.
Matt Westcott