A rendering engine for Django forms using templatetags
Project description
django-boundfield-renderer
A rendering engine for Django forms using templatetags
Preamble
There are already many libraries to render Django forms in templates, including the default Form methods as_p(), as_ul(), as_table(). Unfortunately, none of them (that I have encountered at least) apply strictly the concept of separation of form and function, or business logic from presentation, etc. Django has made a step into the right direction by using templates for the widgets, but the entirety of a field rendering is still partially done in python code. For example, if the developer wishes to put the label after the checkbox, he still has to write python, instead of redefining a template.
This library defines one or more registry, that associate a rendering function (called renderer) for each form field class. That rendering function is made available through the templatetag renderer.
Installation
Add 'boundfield_renderer' to your INSTALLED_APPS setting so Django can find the templatetag renderer.
Basic steps to render a Django Form
Create a registry and register the renderers for the field classes
For example, in the file path/to/my_registry.py
from django import forms
from django.template.loader import get_template
from boundfield_renderer import RendererRegistry
# Create the registry
registry = RendererRegistry()
# Define a renderer function for a field class, for example the CharField
# This can be as simple as the render method of a template
template_render = get_template('mytemplates/char_field.html').render
# Register the renderer for the field class in the registry
# Either by setting it directly on the registry
registry[forms.CharField] = template_render
# Or by using the register method as a decorator on a field class definition
@registry.register(get_template('mytemplates/my_field.html').render)
class MyField(forms.Field):
pass
The file mytemplates/char_field.html could be as simple as this:
<label for="{{ id }}">{{label}}
<input type="text" id="{{ id }}" name="{{ name }}" value="{{ value }}">
</label>
<p>{{ help_text }}</p>
<ul>
{% for error in errors %}<li>{{ error }}</li>{% endfor %}
</ul>
Write a template that renders the form using the renderer template tag
For example, in the file mytemplates/my_form.html
{% load boundfield_renderer %}
<html>
<body>
<form>
{% for boundfield in form %}
{% renderer boundfield 'path.to.my_registry.registry' %}
{% endfor %}
<input type="submit" value="Send">
</form>
</body>
</html>
Renderer function
A renderer function does not have to be a template render method, it can be any method that returns a string. (Must it be marked safe?) It is passed a single parameter that is a dict (called context) with the following key/values:
- form: The form the field belongs to
- boundfield: The bound field itself
- html_name: The HTML name attribute for the field
- value: The current value of the field
- label: The label of the field
- id: The id for the label of the field
- help_text: The help_text of the field
- errors: The list of Validation errors for the field
- disabled: True if the field is disabled
- is_hidden: True if the field is hidden
- required: True if the field is required
Resolution of renderer
To find a renderer for a field class, we follow the MRO order of the field class until we find a renderer registered for that subclass. For example:
from django.core.exceptions import ValidationError
# Override CharField to add some extra clean, BUT DO NOT register a new renderer
class MyCharField(forms.CharField):
def clean(self, value):
if value == 'Spanish Inquisition':
raise ValidationError('I was not expecting the Spanish Inquisition!')
else:
return super().clean(value)
# Override MyCharField AND register a new renderer
@registry.register(get_template('mytemplates/my_other_char_field.html').render)
class MyOtherCharField(MyCharField):
pass
In the first case, the renderer used will be the one we registered for the CharField earlier (template mytemplates/char_field.html). In the second, the renderer used will be the one we registered for MyOtherCharField (template mytemplates/my_other_char_field.html)
If no renderer is found, a ValueError is raised.
renderer templatetag
The renderer templatetag takes a boundfield as the first parameter. It can also take as a second optional parameter a registry object or the full dotted path to a registry object.
If no registry is specified, it will use the default registry as defined in the settings as DEFAULT_BOUNDFIELD_RENDERER_REGISTRY.
For our example this would be:
DEFAULT_BOUNDFIELD_RENDERER_REGISTRY = 'path.to.my_registry.registry'
Finally, the renderer tag can take optional keyword parameters that will be added to the context.
If we reuse our previous example form template mytemplates/my_form.html, we could change the context for a particular field "starwberry" to add a context variable "css_classes" with a value of "forever":
{% load boundfield_renderer %}
<html>
<body>
<form>
{% for boundfield in form %}
{% if boundfield.name == 'strawberry' %}
{% renderer boundfield 'path.to.my_registry.registry' css_classes='forever' %}
{% else %}
{% renderer boundfield 'path.to.my_registry.registry' %}
{% endif %}
{% endfor %}
<input type="submit" value="Send">
</form>
</body>
</html>
Note on renderer registration
The code that registers the renderer for a form field class must be executed by Django before the renderer templatetag is called.
Practically, this can be achieved by registering the renderers in the same file where the registry is defined, or in the files where the form field class are defined (for example using the register decorator)
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
File details
Details for the file django-boundfield-renderer-1.4.tar.gz.
File metadata
- Download URL: django-boundfield-renderer-1.4.tar.gz
- Upload date:
- Size: 7.2 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/1.13.0 pkginfo/1.5.0.1 requests/2.22.0 setuptools/41.0.1 requests-toolbelt/0.9.1 tqdm/4.32.1 CPython/3.6.8
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 | 01192f0393594af6d15d80f77c509b1f392b1c3fedbe5addd18b39463524c1df |
|
| MD5 | 3e7840602d3307ae8908587a320d7868 |
|
| BLAKE2b-256 | 2eae7598be61b3ac790130ad5ba85cae40a343b96317a74149d8ce01b840d020 |
File details
Details for the file django_boundfield_renderer-1.4-py2.py3-none-any.whl.
File metadata
- Download URL: django_boundfield_renderer-1.4-py2.py3-none-any.whl
- Upload date:
- Size: 10.8 kB
- Tags: Python 2, Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/1.13.0 pkginfo/1.5.0.1 requests/2.22.0 setuptools/41.0.1 requests-toolbelt/0.9.1 tqdm/4.32.1 CPython/3.6.8
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 | 698df3a55b58b9d4c56c6703c32246defcb021ccbcd101cd5cf618464ecd4889 |
|
| MD5 | 5f9bc93506e52773b7d7a04d85c8c3f8 |
|
| BLAKE2b-256 | a003c44b7d6788040f49839a4f0138115f066e28286dc8359ab2858b71462de2 |
