I know that you can use an alternative template engine. AFAIK Jinja2, maybe others, too.
What are your experiences?
Sometimes I really think it would be nice to able to do method calls.
Sometimes I prefer to use format_html() since it is easier, since writing Python feels easy for me.
Are you happy with the default template engine?
Thanks to this year’s community survey we have some data on this question. 94% of developers use Django Templates, and 18% use Jinja2. So most people seem to be happy enough with the default engine, or will use Jinja2 where it makes sense.
Not only am I “happy” with the default engine, I find it far superior than any of the other environments in which I’ve worked.
Personally, I really appreciate how Django handles this. I’ve spent too much time in the Java world in applications where the code logic is split between multiple layers and it’s incredibly frustrating to have to find out where some data element on the page is actually being retrieved or calculated.
I like the concept that all your data needs to be aggregated in your view and prepared prior to rendering the HTML. (It has also made it easier and cleaner for us to reuse some of those views when we want to generate something other than HTML.)
I think it’s a huge plus to have a templating language that actually tries to make it difficult to do things that end up being a maintenance nightmare.
Yes, in general I like the Django Templates, too.
But I would like to get an exception if an unknown variables gets accessed, since this means
(my point of view) that there is an error in the code. And you know “errors should never pass silently”.
But yesterday I discovered something great: https://pytest-django.readthedocs.io/en/latest/usage.html#additional-command-line-options
I activate this pattern via pytest.ini:
[pytest]
DJANGO_SETTINGS_MODULE = mysite.settings
FAIL_INVALID_TEMPLATE_VARS = True
Now I found a solution to one of the pain-points I had with the django template engine.
thank you for your answers!
I disagree with this. I consider the ability of Django to ignore undefined references to be a strength.
The benefit of doing this is that it allows us to make our templates a lot more generic and flexible with a minimum of additional work.
To say that an undefined variable is an error, means that every variable would need to be defined in every view rendering a template which could be a significant amount of additional work.
The alternative would be adding if tags around every optional component - which would require an additional directive, since the current templating language doesn’t have a separate if exists type of construct.
With the idea that all undefined variables is an error, something like:
{% if group_name %} </optgroup>{% endif %}
(in django.forms.templates.django.forms.widgets.select) wouldn’t even be valid without ensuring that every context that ends up rendering the select widget directly or indirectly has a goup_name defined at that layer of the context.
I created this snippet 12 years ago: https://djangosnippets.org/snippets/646/
It is funny, this snippet is visible again and again in StackOverlfow answers or in pytest:
For example in pytest-django: https://github.com/pytest-dev/pytest-django/blob/bd2ae62968aaf97c6efc7e02ff77ba6160865435/pytest_django/plugin.py#L541
If there would be no demand for this, the snippet would not spread.
I am very opinionated concerning “error should never pass silently”. For me it is an error,
and I want to see an exception, not an empty string. It is like a shell script which
just executes the next line if one line fails. Sorry, I can’t build reliable products with it.
But I am very happy that Django is unopinionated here. You can use the default, or
you can use the “missing means error” approach.
There is a even a project which monkey-patches some django methods to get an exception
in every case: https://pypi.org/project/django-shouty-templates/
I have to point out that I find this quite funny. Django itself is considered reliable and relies upon this precise mechanic.
Seems to me that there’s a vast difference between silence being an error in a script, and silence rendering a blank string in a template engine.