Язык шаблонов для Django, который не вызывает молчания при исключении? - PullRequest
Новая
       3

Язык шаблонов для Django, который не вызывает молчания при исключении?

3 голосов
/ 02 апреля 2020

Мне нравится django, ORM, админ, сообщество. Но мне не нравится обработка исключений в языке шаблонов, как описано здесь: недопустимые переменные шаблона .

Есть ли альтернативная переменная шаблона, где я всегда получаю исключение, если что-то неправильно (даже в производстве)?

Я предпочитаю исключения "молча игнорировать ошибки".

1 Ответ

4 голосов
/ 14 апреля 2020

Одним из решений было бы изменить бэкэнд вашего шаблона на jinja2 (который поддерживается "изначально" Django) , следуя документации .

Подробное объяснение как jinja2 django обрабатывает проблему переменной undefined, можно найти здесь (обозначение) :

Invalid переменные шаблона

Вы можете установить различные варианты поведения, когда в шаблонах Jinja встречается недопустимая переменная. Django устанавливает для Jinja два поведения по умолчанию: одно для случая, когда DEBUG=True - общий параметр в разработке, а другое для случая, когда DEBUG=False - общий параметр в рабочем состоянии.

Если DEBUG=True и недопустимая переменная установлена ​​в шаблоне Jinja, Jinja использует класс jinja2.DebugUndefined для его обработки. Класс jinja2.DebugUndefined дословно выводит переменную для рендеринга (например, если шаблон имеет оператор {{foo}}, а переменная не существует в контексте, Jinja выводит {{foo}}, что упрощает поиск недопустимой переменной).

Если DEBUG=False и недопустимая переменная установлена ​​в шаблоне Jinja, Jinja использует класс jinja2.Undefined для его обработки. Класс jinja2.Undefined выводит пробел в позиции переменной для рендеринга (например, если шаблон имеет оператор {{bar}}, а переменная не существует в контексте, Jinja выводит пробел). Стоит упомянуть, что это последнее поведение соответствует поведению по умолчанию недопустимых переменных в шаблонах Django.

В дополнение к классам jinja2.DebugUndefined и jinja2.Undefined Jinja также поддерживает jinja2.StrictUndefined класс. Класс jinja2.StrictUndefined используется для генерирования немедленной ошибки вместо продолжения рендеринга, что полезно для более быстрой диагностики недопустимых переменных. Однако имейте в виду, что последний класс меняет свое поведение на основе переменной DEBUG, он либо генерирует ошибку стека с недопустимым именем переменной (т. Е. Когда DEBUG=True), либо генерирует стандартную страницу ошибки HTTP 500 (т. Е. когда DEBUG=False).

Если вы хотите установить опцию StrictUndefined в своем шаблоне, вы можете использовать следующий пример из того же источника :

Листинг 4-4. Сгенерируйте ошибку для недопустимых переменных в Jinja с помощью jinja2.StrictUndefined

import os

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
PROJECT_DIR = os.path.dirname(os.path.abspath(__file__))

import jinja2

TEMPLATES = [    
    { 
        'BACKEND':'django.template.backends.jinja2.Jinja2',
        'DIRS': ['%s/jinjatemplates/'% (PROJECT_DIR),],
        'APP_DIRS': True,
        'OPTIONS': {
            'undefined':jinja2.StrictUndefined
        },
    }            
]

. Как видно из листинга 4-4, мы сначала объявляем import jinja2, чтобы получить доступ к классам Jinja в settings.py. Затем мы объявляем неопределенный ключ внутри параметра OPTIONS и назначаем ему класс Jinja для обработки недопустимых переменных. В этом случае мы используем класс jinja2.StrictUndefined для получения ошибок, когда встречаются недопустимые переменные шаблонов, но вы также можете использовать любой из двух других классов Jinja для обработки недопустимых переменных (т. Е. jinja2.DebugUndefined или jinja2.Undefined).

Наконец, если вы хотите иметь другое поведение между DEBUG=True или DEBUG=False, вы можете изменить следующее в настройках TEMPLATES: 

'OPTIONS': {
    'undefined': jinja2.DebugUndefined if DEBUG else jinja2.StrictUndefined
},

Использование опции отладки jinja2 на разработку и строгие варианты производства (ошибки, как указано в вопросе).

...