Tag: django

Django 1.8 以後已經可以選擇使用自家的 template engine 或是使用 jina2 template engine 了，而且是可以混用，不限制你只能使用其中一種。

第一步是先安裝 jinja2：

pip install jinja2

第二步是在 settings 裡的 TEMPLATES 裡增加 jinja2 的設定：

TEMPLATES = [
    # 省略 django template 的設定
    {
        'NAME': 'jinja2',
        'BACKEND': 'django.template.backends.jinja2.Jinja2',
        'DIRS': [
            # insert more TEMPLATE_DIRS here
            # join(BASE_DIR, 'templates'), 
        ],
        'APP_DIRS': True,
        'OPTIONS': {
            'environment': 'your_project.jinja2.environment',
        },
    },
]

 

第三步，是在 your_project 下建立 jinja2.py ，內容：

#!/usr/bin/env python
# -*- coding: utf-8 -*-
from __future__ import absolute_import    # 使用 absolute_import 很重要!!!
import logging
from django.utils import translation
from django.contrib.staticfiles.storage import staticfiles_storage
from django.urls import reverse
import jinja2


logger = logging.getLogger(__name__)


def environment(**options):
    env = jinja2.Environment(
        extensions=['jinja2.ext.i18n', 'jinja2.ext.with_'],
        **options)
    env.globals.update({
        'static': staticfiles_storage.url,
        'url': reverse,
    })
    env.install_gettext_translations(translation)    # 使用 django 的 i18n/l10n
    return env

在這裡，我遇到一個奇怪的狀況，python 2 一直告訴我 jinja2 沒有 Environment，後來看了這篇，才知道是 absolute/relative import 問題，使用 absolute_import 以確保 import 的 jinja2 是正確的，而不是 django 的 jinja2。我想，python 3 應該不會有這問題。

django template 是使用 load 載入模組，jinja2 則需要在 Environment 初始化時就定義。

第四步，是在繼承 TemplateView 的類別裡，加入

template_engine = 'jinja2'

，然後在 your_app 下建立 jinja2 路徑，將 template 檔案放在那裡即可。

class Jinja2Test(TemplateView):
    template_name = 'jinja2test.html'  # template file 的名稱是 jinja2test.html ，檔案必須放在 your_app/jinja2 下。
    template_engine = 'jinja2'  # 表示要使用 jinja2 template engine，這個 jinja2 是定義在 settings 裡的 NAME

    def get_context_data(self, **kwargs):
        ctx = super(Jinja2Test, self).get_context_data(**kwargs)
        ctx['foo'] = 'bar'
        ctx['hello'] = 'world'
        return ctx

參考資料：

• Using Jinja2 with Django (1.8 onwards)
• Django Templates
• Django 的模版與 Jinja2
• Django + Jinja2 + i18n

在 Django 裡使用了某個 package，但該 package 沒有自己所用的 locale 時，該怎麼做呢?

以下以 django-mptt 為例：

1. 先確認 site-packages 下 django-mptt 的目錄名稱，在安裝 django-mptt 以後，實際上是 mptt，所以在專案目錄下建立 mptt/locale 。
2. 到 site-packages/mptt 下，執行 django-admin makemessages –locale=zh_TW
3. 將 site-packages/mptt/locale/zh_TW 搬移到專案目錄下的 mptt/locale
4. 使用 poedit 或其他工具進行翻譯
5. 調整 django settings 裡的 LOCALE_PATHS，例如：

   from os.path import dirname, join
   BASE_DIR = dirname(dirname(dirname(__file__)))
   # ...略...
   LOCALE_PATHS = [
       join(BASE_DIR, 'locale'),
   
       # customize translations which package is in site-packages
       join(BASE_DIR, 'mptt', 'locale'),
   ]
   

這樣就大功告成了。

前幾天想知道我 Django 程式裡某段函式的瓶頸，所以查了 Django 怎麼做 profiling 。是有查到有 jazzband/silk: Silky smooth profiling for Django 這個 package ，但是有點太大。如果是用常找到的

python -m cProfile xxx.py xxx.py

，Django 程式又不太適合。畢竟我只是想查某個函式而已。所以後來查到這兩個 decorator：

• Simple little profiling decorator in python.
• Python profiling decorator

使用上很簡單，程式放進去，在想做 profiling 的函式前加上 decorator 就可以了。

我用的是第一個，在加上 decorator，執行過程式（應該說是瀏覽網頁）以後，在程式當前資料夾裡會找到 .profile 的檔案，為了後續方便說明，假設產生出來是 func.profile 。有這個檔案以後，就可以用

python -m pstats func.profile

開啟，開啟以後，是 pstats 的 shell ，一般要查哪個地方花的時間最多，會用

sort time

依照執行花費時間來排序，再用

stats 10

列出前十個花費時間最多的函式。

參考資料：

• Handy Python profiling analysis with pstats’ interactive browser – Stefaan Lippens inserts content here
• python – How can you profile a script? – Stack Overflow

出乎意料的簡單，原本還以為很麻煩的：django revert last migration – Stack Overflow

先執行 ./manage.py showmigrations my_app 列出所有的 migrations

然後執行 ./manage.py migrate my_app <0010_previous_migration>

這樣就可以 Revert 了。

同事問，為什麼用 model 建立 instance 以後，呼叫 save 沒有觸發 validate?

上網找了一下，大致有兩種方法：

1. 用 ModelForm 的 is_valid() 做檢查，Correct Way to Validate Django Model Objects?
2. 覆寫 model 的 save()，Django model mixin to force Django to validate (i.e. call `full_clean`) before `save`

事情沒有這樣結束，因為很好奇 Django 的作法，就去追 Code。

如果是走 is_valid() ：

1. forms/models.py：ModelForm 繼承自 BaseModelForm，而 BaseModelForm 又繼承自 BaseForm，這個檔案裡，沒有看到 is_valid
2. forms/forms.py：
   1. BaseForm.is_valid() 很簡單的只回傳 self.is_bound and not self.errors ，self.is_bound 跳過不看，self.errors 是一個 property，裏面呼叫了 self.full_clean()
   2. self.full_clean() 呼叫了 self._clean_fields(), self._clean_form() 與 self._post_clean() ，關鍵在 self._post_clean() 。BaseForm 裡的 _post_clean() 是空的，讓繼承 BaseForm 的類別去決定。
3. forms/models.py: 回頭看 BaseModelForm._post_clean()，這裡呼叫了 self.instance.full_clean() ，並處理 ValidationError 。instance 就是 model 類別所創出的實體，Model 繼承自 ModelBase 所以接著看 ModelBase 類別。
4. db/models/base.py: ModelBase 的 full_clean() 呼叫了 self.clean_fields(), self.clean() 與 self.validate_unique ，並且在這裡處理了 ValidationError 例外，最後判斷了 errors 裡是否有東西，有的話，丟出 ValidationError。先看 self.clean_fields() ，函式裡去取得定義在類別裡的欄位，並且呼叫每個欄位 (Field) 類別的 clean() 函式。如果有錯誤就丟出 ValidationError()
5. db/models/fields/__init__.py：Field 類別定義在這個檔案裡，裏面的 clean() 呼叫了 self.validate() 、self.run_validators()

至此，ModelForm 的路徑就確定了。

來看看第二個方法，他是要求 Model 類別除了繼承 Django Model 之外，再繼承 ValidateModelMixin 這個自訂類別以覆寫 save() ，看看裏面的 save()，就只是多呼叫了 full_clean() 來檢查，也就是走上述步驟 4 以後的路線。

Django 官方網站不建議直接去呼叫 full_clean() 這件事，不過找了一下，也沒找到什麼更好的解法~

P.S.

• 這篇 About Django’s model- and form validations 也寫的不錯。
• 這篇看的是 Django 1.8 的原始碼。