DjangoBB LoFi version

Найти - Пользователи

Полная версия: Проблемы с точками в шаблонизаторе Django

Начало » Django » Проблемы с точками в шаблонизаторе Django

1 2 3 4

regall

Ноя. 12, 2009 09:19:08

Naota
Беру свои слова назад) Кустомайзинг джанго админки очень радует.

Это не спасет отца русской демократии ….

Evg

Ноя. 12, 2009 09:46:20

regall
regall написал:

{{ <Словарь>.<объект>.<свойство>.<индекс> }}

По-моему тут чисто отображение и никакой логики.

Не соглашусь, в идеале шаблон вообще должен получать имя параметра и значение, в нем не должно быть известно как связаны объекты, и то что вы там делаете длинный путь это уже часть логики которой там не должно быть.

В идеале даже лучше передавать например не user
а потом в шаблоне делать user.username, а передавать именно user.username и там делать {{username}}
хотя я сам так не делаю)
ну а то что уж через 4-е точки так это перебор точно.

regall

Ноя. 12, 2009 10:14:23

Evg
В идеале даже лучше передавать например не user
а потом в шаблоне делать user.username

Да, а если таких свойств у моего ‘user’ - 1000 штук, мне что все поименно передавать?

Evg
в идеале шаблон вообще должен получать имя параметра и значение

Ну, нужно мне отображать многоуровневые списки, так как мне это сделать. Самый классный вариант - словари, хуже - туплы туплов и т д.
Как мне в таких случаях поступать?

P. S.
Постепенно привыкаю строить для шаблонизатора “извращенные” дикты, которые он может понят, недавно познакомился со штукой, которая мне действительно понравилась - это тег “regroup”.

Evg

Ноя. 12, 2009 12:00:29

regall
Да, а если таких свойств у моего ‘user’ - 1000 штук, мне что все поименно передавать?

в идеале да) иначе ваш шаблон будет жестко завязан на логику в кот учитываются все эти пути. И например в другом месте его уже не заинклудить.

regall
Ну, нужно мне отображать многоуровневые списки, так как мне это сделать. Самый классный вариант - словари, хуже - туплы туплов и т д.
Как мне в таких случаях поступать?

судя по примеру вам нужно отображать не многоуровневые списки а иметь доступ из шаблона лазить по таким структурам, так вот такой логики в шаблонах не должно быть. Лучше шаблоны связывать с отображением одной сущности, а логику связей выносить в вид или в тег.

regall

Ноя. 12, 2009 13:41:54

Evg
судя по примеру вам нужно отображать не многоуровневые списки

Из этого примера да, а если нцжно отображать списки многоуровневые? Я с этой проблемой столкнулся, решал примерно следующим образом.
Было:

{<title1>:
      {<title2>:
       (<element1>,<elements2>, ..., <element n>, )}
}

Получилось:

{'title':<title1>, 'sublist':
      {'title':<title2>,'sublist':(<element1>,<elements2>, ..., <element n>, )}}

Такое уже шаблонизатор хавает =)

Evg

Ноя. 12, 2009 14:00:39

У вас там выводы каких то мудренных статистик что-ли? у меня просто таких проблем не бывает обычно, и я думаю их не должно быть, передаю модели максимум в шаблон, если у нее есть подсписок то он через метод забирается в шаблоне и для него через тег или инклуд строится его вывод. Ну а если там какая то мудренная статистика то может стоит ее адаптировать к выводу через некий объект, чтобы в шаблоне это было все просто и явно.

Те я о том что у вас там как то все намешано в кучу, я подозреваю что вместо вот этого:

regall
{'title':<title1>, ‘sublist’: {'title':<title2>,'sublist':(<element1>,<elements2>, …, <element n>, )}}

нужно передовать не всю эту кашу, а просто начальный список объектов.
А в шаблоне должно быть так:

{% for o in objs1 %}
{{o.title}}
    {%for o2 in o.getsublist%}
    {{o2.title}}
             {%for o3 in o2.getsublist%}
             {{o3.title}}
              {% endfor %}
    {% endfor %}
{% endfor %}

А вы как будто все это повыдрали кусками и зачем-то выдаете в словаре.

regall

Ноя. 12, 2009 15:14:51

Evg
У вас там выводы каких то мудренных статистик что-ли?

Вообще-то, какая разница, какая задача? Есть средство и оно должно решать задачу…

Evg
А вы как будто все это повыдрали кусками и зачем-то выдаете в словаре.

Да, так и есть, это информация фактически “выдрана кусками” из самых различных частей БД в 100 таблиц, и иначе как словарем не получится (так как писать для 15 различных классов специально для шаблонизатора методы “getsublist”, уж увольте =)).

Evg

Ноя. 12, 2009 15:24:36

regall
Вообще-то, какая разница, какая задача? Есть средство и оно должно решать задачу…

Смотря какая задача и какое средство)

regall
Да, так и есть, это информация фактически “выдрана кусками” из самых различных частей БД в 100 таблиц

А с бд вы тоже напрямую работайте, не через ОРМ джанги?)

regall

Ноя. 12, 2009 15:39:29

Evg
Смотря какая задача и какое средство)

Evg
А с бд вы тоже напрямую работайте, не через ОРМ джанги?)

Видно вы только с сайтами-визитками сталкивались, в моем случае БД модифицируется/расширяется очень часто, если не будет правильнее сказать постоянно; порой приходится делать вот такие вот “выдирания из разных частей базы”, как ни прискорбно, но задачи такие, что от этого не уйдешь =(

Evg

Ноя. 12, 2009 15:45:30

regall
в моем случае БД модифицируется/расширяется очень часто

А модели через которые идет работа с бд при этом у вас не меняются, я так понял?)