django-render-block 0.9.1

Render a particular block from a template to a string.

Django Render Block

Render the content of a specific block tag from a Django template. Works for arbitrary template inheritance, even if a block is defined in the child template but not in the parent. Generally it works like render_to_string from Django, but allows you to specify a block to render.

Features

• Render a specific block from a template
• Fully supports the Django templating engine
• Partially supports the Jinja2 engine: it does not currently process the extends tag.

Requirements

Django Render Block supports Django 2.2, 3.1, 3.2, and 4.0 on Python 3.6, 3.7, 3.8, 3.9, and 3.10 (see the Django documentation for which versions of Python are supported by particular Django versions).

Examples

In test1.html:

{% block block1 %}block1 from test1{% endblock %}
{% block block2 %}block2 from test1{% endblock %}

In test2.html:

{% extends 'test1.html' %}
{% block block1 %}block1 from test2{% endblock %}

And from the Python shell:

>>> from render_block import render_block_to_string
>>> print render_block_to_string('test2.html', 'block1')
u'block1 from test2'
>>> print render_block_to_string('test2.html', 'block2')
u'block2 from test1'

It can also accept a context as a dict (just like render_to_string), in test3.html:

{% block block3 %}Render this {{ variable }}!{% endblock %}

And from Python:

>>> print render_block_to_string('test3.html', 'block3', {'variable': 'test'})
u'Render this test!'

API Reference

The API is simple and attempts to mirror the built-in render_to_string API.

render_block_to_string(template_name, block_name, context=None, request=None)

template_name

The name of the template to load and render. If it’s a list of template names, Django uses select_template() instead of get_template() to find the template.

block_name

The name of the block to render from the above template.

context

A dict to be used as the template’s context for rendering. A Context object can be provided for Django templates.

context is optional. If not provided, an empty context will be used.

request

The request object used to render the template.

request is optional and works only for Django templates. If both context and request are provided, a RequestContext will be used instead of a Context.

Exceptions

Like render_to_string this will raise the following exceptions:

TemplateDoesNotExists

Raised if the template(s) specified by template_name cannot be loaded.

TemplateSyntaxError

Raised if the loaded template contains invalid syntax.

There are also two additional errors that can be raised:

BlockNotFound

Raised if the block given by block_name does not exist in the template.

UnsupportedEngine

Raised if a template backend besides the Django backend is used.

Contributing

If you find a bug or have an idea for an improvement to Django Render Block, please file an issue or provide a pull request! Check the list of issues for ideas of what to work on.

Attribution

This is based on a few sources:

• Originally Django Snippet 769
• Updated version Django Snippet 942
• A version of the snippets was ported as Django-Block-Render
• Additionally inspired by part of django-templated-email
• Also based on a StackOverflow answer 2687173

Changelog

0.9.1 (December 15, 2021)

• Support Python 3.10. (#33)
• Fixed a packaging issue where the generated wheels were empty. Contributed by @cordery. (#35)

0.9 (December 14, 2021)

• Drop support for Django 3.0. (#31)
• Support Django 3.2 and 4.0. (#27, #31)
• Switch continuous integration to GitHub Actions. (#26, #28)
• Changed packaging to use setuptools declarative config in setup.cfg. (#32)

0.8.1 (October 15, 2020)

• Fixes a regression in v0.8 where a Context could not be re-used. Contributed by @evanbrumley. (#25)

0.8 (October 6, 2020)

• render_block_to_string now forwards the Context passed as context parameter. Contributed by @bblanchon. (#21)
• Drop support for Python 3.5, support Python 3.9. (#22)

0.7 (July 13, 2020)

• Drop support for Django < 2.2. (#18)
• Support Django 3.0 and 3.1. (#18, #20)
• Drop support for Python 2.7. (#19)
• Support Python 3.8. (#18)

0.6 (May 8, 2019)

• Support Django 1.11, 2.1, and 2.2. (#9, #11, #17)
• Support Python 2.7, 3.5, 3.6, and 3.7. (#9, #17)
• render_block_to_string now optionally accepts a request parameter. If given, a RequestContext instead of a Context is used when rendering with the Django templating engine. Contributed by @vintage. (#15)
• Fix rendering of README on PyPI. Contributed by @mixxorz. (#10)

0.5 (September 1, 2016)

• Fixes a major issue with inheriting templates and rendering a block found in the parent template, but overwriting part of it in the child template. (#8)

0.4 (August 4, 2016)

• Initial support for using the Jinja2 templating engine. See README for caveats. (#3)
• Support Django 1.10. (#5)
• Support Python 3. (#6)

0.3.1 (June 1, 2016)

• Refactoring to make more generic (for potentially supporting multiple templating engines).

0.3 (May 27, 2016)

• Largely rewritten.
• Support Django 1.8 and 1.9:
  • Guards against different template backends.
  • Uses internal APIs for each node.
  • Removed context_instance parameter.
  • Support for calling {{ block.super }}.

0.2.2 (January 10, 2011)

• Updated per comment 3466 on Django Snippet 942 by eugenyboger to fix an issue with nested extends. The specific bug was not reproducible, but the additional code shouldn’t hurt.

0.2.1 (August 27, 2010)

• Updated per comment 3237 on Django Snippet 942 by chadselph to remove a pointless render. The specific bug was not reproducible, but the removed code was extraneous.

0.2 (August 4, 2008)

• Updated version from Django Snippet 942 by zbyte64.
• Improves include:
  1. Simpler/better handling of “extends” block tag
  2. Searches If/Else blocks
  3. Less code
  4. Allow list of templates to be passed which is closer to the behavior of render_to_response

0.1 (May 22, 2008)

• Initial version from Django Snippet 769 by sciyoshi.
• Support Django 0.96.