This article is Day 16 of Django Advent Calendar 2016.
Simply put, it's a Python template engine. Official page: http://jinja.pocoo.org/ Inspired by Django's template engine, it looks the same as Django's default template engine. Jinja2 is more feature-rich than Django's template engine, and can be used for other purposes such as LaTex and email, rather than a template engine dedicated to writing HTML and XML.
Officially supported since 1.8 on Django. (Installation of library is required)
By the way, the origin of the name is If you translate the shrine into English, Temple, Template and Temple have similar pronunciations → It seems to be Jinja w
I'm new to Django, so I've never used Jinja2 with Django asking if I should use the default template engine for the time being. I've used it in Other Uses (I'm sorry for my article w), but I haven't done anything special, so I read the documentation so much. There is no such thing.
~~ Rails is more accustomed to web framework development than Django, so I really want to use Ruby Slim ~~ There is a more convenient template engine to make development easier. I wanted to use it if possible, so this time I decided to investigate Jinja2 focusing on the use in Django.
It seems that Django also has a slim-like template engine, but I stopped it because there is little information and it seems to be troublesome to look up.
** This article only writes about Django, so I won't cover it for any other purpose. ** **
Actually replacing the Django template with Jinja2 seemed to be difficult, so this time I just replaced a small part of the existing project with a trial. As I will write in the next introduction item, the default template engine and Jinja2 were mixed in one project. ** Python 3.3 and above does not seem to be fully supported **, so you should be careful if you are using 3.4 or above. However, since the test itself has passed, even if there are bugs, only small ones will be. http://jinja.pocoo.org/docs/dev/intro/#experimental-python-3-support
Rewrite TEMPLATE in Django's settings.py as follows:
By default, Jinja2 will look for template files in the jinja2 directory, so switching to Jinja2 just for BACKEND will not work as usual.
It seems that it is necessary to change the templates directory name of each application to jinja2 or explicitly specify it with DIRS.
In the example below, the Jinja2 setting is added to the usual (?) Setting.
In my local development environment, I put django_debug_toolbar etc., but in order to pass the path to the templates of these libraries, I had to put the usual template settings as well. In a production environment, these libraries are not used, and only the templates defined by themselves are used (probably), so it seems that only the Jinja2 settings are sufficient.
TEMPLATES = [
{
'BACKEND': 'django.template.backends.jinja2.Jinja2',
'DIRS': [os.path.join(BASE_DIR, 'templates/jinja2')],
'APP_DIRS': True,
},
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [],
'APP_DIRS': True,
'OPTIONS': {
'context_processors': [
'django.template.context_processors.debug',
'django.template.context_processors.request',
'django.contrib.auth.context_processors.auth',
'django.contrib.messages.context_processors.messages',
],
},
},
]
The documentation is extensive, but there are many parts that aren't relevant for use as Django's template engine, so for now, just take a look at the URL below and you'll see what you can do. http://jinja.pocoo.org/docs/dev/templates/#synopsis
Although it is called Django Inspire, there are many differences in detailed specifications, so I will introduce only the major differences.
With JinJa2, you can write processing like Python even on a template.
As shown below, Django does not have (), but Jinja2 has ().
Django: {% for page in user.get_created_pages %}
Jinja2: {% for page in user.get_created_pages() %}
Thanks to this, you can do something like Add order_by to your Django model on the template side. However, I don't think it's cool to squeeze such a description on the template side.
http://jinja.pocoo.org/docs/dev/templates/#macros In Django, if you want to do something other than the processing provided from the beginning on the template, I think you defined your own template tag, but in Jinja2, you define it using something called macro. The macro defined in the template can be reused by using call. I will omit the details w
http://jinja.pocoo.org/docs/dev/templates/#list-of-builtin-filters There are surprisingly many filters. A quick look, Python arrays, strings, and numeric objects can be used or the methods they have are relatively usable.
http://jinja.pocoo.org/docs/dev/templates/#math I use django-mathfilter when I want to perform four arithmetic operations on a template with Django, but Jinja2 doesn't seem to need it. It's sober, but I'm happy. There are also many comparison operators.
It's overwhelmingly easier than creating and using template tags by yourself.
For example, when you want to display the following variables in a template,
foo = {"bar": 1}
For Django's default template
foo.bar
Therefore, you cannot write foo ["bar "], but in the case of Jinja2, you can also use foo ["bar "].
I'm also happy because it always felt strange to access dict variables with dots.
http://qiita.com/ryu22e/items/e50f8a3fbd6fe836c1b4 I will not write it because some people have already written the article. I think that context_processor is applicable to Django's default template engine, but I'm not sure if the ability to set global variables is the advantage of Jinja2 because I have never made it myself.
It has more features than I expected, and it has become a rough article.
It's very versatile and I want to use it right away, but while it's called Django Inspire, there are many minor differences, and I got the impression that replacing an existing project with Jinja2 seems a bit annoying. When switching to slim with Rails, there is a conversion command, so it was relatively easy to switch, but Jinja2 seems to be impossible unless you check everything properly. I would like to try it when creating a new application.
Also, I don't think it's good to stuff the logic on the template side or touch the data in the first place, so I thought that I had to be especially careful when using Jinja2. The same thing is written in the document. http://jinja.pocoo.org/docs/dev/faq/#isn-t-it-a-terrible-idea-to-put-logic-into-templates
Recommended Posts