Как «преобразовать типы» и починить странную работу if в Jinja?

Question

[Сергей Еремин]

Столкнулся со странностью работы шаблонизатора Jinja в Django. Нужно установить selected для обработанного выпадающего списка option. Делаю так:

<select name="ft">
    <option value="0">Все ({{ total_item }} шт.)</option>{% for i in menu_typ %}
    <option value="{{ i.id }}"{% if request.GET.ft == i.id %} selected{% endif %}>
        {{ i.szName|capfirst }} ({{ i.Num }} шт.)
    </option>{% endfor %}
</select>

Никаких selected ни для одного option не появляется.
, {% if request.GET.ft == i.id %} не срабатывает в принципе. Всевозможные эксперименты показали, что причина несоответствие типов: i.id -- число; request.GET.ft -- строка. Привести обе переменные к одному типу удалось с помощью костыля add -- {% if request.GET.ft|add:0 == i.id|add:0 %}. Таким образом, если сделать вот так:

<select name="ft">
    <option value="0">Все ({{ total_item }} шт.)</option>{% for i in menu_typ %}
    <option value="{{ i.id }}"{% if request.GET.ft|add:0 == i.id %} selected{% endif %}>
        {{ i.szName|capfirst }} ({{ i.Num }} шт.)
    </option>{% endfor %}
</select>

Всё работает. Это костыль, или все так делают? Какие ещё есть варианты??

Answer 1

[Animkim]

Не проще там же где и menu_typ, всё это дело обработать и вернуть список какого-то такого вида:

[{'object': object, 'selected': 'selected'},  {...}, {...}]

# html
{% for item in menu_typ %}
   <option value="{{ item.object.id }}" {{ item.selected }}>
        {{ item.object.szName|capfirst }} ({{ item.object.Num }} шт.)
    </option>
{% endfor %}

или [(object, 'selected'),  {object, ''), (...)]

{% for item, selected in menu_typ %}
   <option value="{{ item.id }}" {{ selected  }}>
        {{ item.szName|capfirst }} ({{ item.Num }} шт.)
    </option>
{% endfor %}

Comments

[Сергей Еремин]

Понятно, что можно все get на уровне вьюшки обработать, сформировать признаки какие пункты меню активировать, какие скрыть, что "заселекчено" и "зачекено"... и я раньше именно так и делал... но по факту получается, что две треть вьющки обрабатывает вот это вот все (с проверкой есть значение или нет, находится ли оно в допустимых пределах, правильный ли у него тип...). А это, мало относится к логике действительно важно на бекенде. Все эти get переменные, заведующие тем как отображать интерфейс, можно (и мне кажется, правильно) отработать в шаблонах. Учитывая, что шаблоны поддерживают наследование -- это очень удобно. Шаблон не становится более громозкий, потому что все равно надо проверять пришла переменная заведующая отображением. И не важно из словаря бэкаенда это получено или сразу их get... Но вот с преобразованием типов -- засада.

[Animkim]

Сергей Еремин, если сложить всё это в шаблоны, то потом очень сложно это поддерживать. Если интерфейс сложный, я обычно под него завожу отдельный класс и в шаблоне только дергаю методы этого класса. С таким подходом я очень, очень редко опускаюсь до уровня html. Один раз написал и забыл, если надо что-то поправить иду и правлю пайтон код.

[Сергей Еремин]

Animkim, Мне как раз кажется, что благодаря тому, что шаблоны можно делать каскадными. Как раз все GET-переменные заведующие отображением меню и интерфейсов очень в них удобно обрабатывать. К тому же это унифицирует использование "интерфейсных" GET-переменных.

Возможно не прав.

Answer 2

[Роман]

я бы во вьюхе в контекст добавил переменную ft = int(request.GET.ft) и в шаблоне сравнивал их {% if ft == i.id %}

Comments

[Сергей Еремин]

К этому шаблону (а он сильно вложен) по факту обращаются из кучи вьюх... Он заведует исключительно отображением состояния, и это состояние получает через переменную get... самой вьюхе (а их же много) вообще не важно в каком состоянии был интерфейс. Возможно в нем какой-то другой кусок будет использоваться (например, когда на веб-странице много форм). Придется в каждой вьюхе обрабатывать (делать преобразование типов) то что к ее фунционалу не относится...