Django - использовать общие представления или нет?

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

Это основная идея, насколько я понимаю:

1) Запрос -> Шаблоны URL -> Вид -> Шаблон

or

2) Запрос -> шаблоны URL (общий вид) [-> необязательный шаблон]

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

Мне очень нравится идея иметь шаблоны URL только шаблоны, а не добавлять дополнительный шаблон. Мне также нравится идея явного определения всех представлений, даже самых простых, чтобы позже я знал, где их найти, не переходя взад и вперед по файлам. Кроме того, мы все знаем, что любую автомагию сложнее настроить, чем то, что вы создаете с нуля (по крайней мере, с нуля Django).

Я что-то упускаю? Совершаю ли я большую ошибку, которая будет преследовать меня позже, если я вообще не использую общие представления?


python django django-generic-views
person Ska    schedule 26.06.2011    source источник

Ответы (3)


arrow_upward
10
arrow_downward

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

Если вы используете представления на основе классов django-1.3, вместо передачи множества переменных функции в urls.py вы можете переопределить соответствующие интересующие методы, что обеспечивает лучшее из обоих миров. - Меньше кода и больше контроля.

person lprsd    schedule 26.06.2011
comment
+1: я обнаружил, что общие представления работают для очень специфических типов сопоставлений URL-адресов и страниц. Неудивительно, что они, как правило, ориентированы на газеты (и блоги). - person Peter Rowell; 27.06.2011
comment
@PeterRowell, вы говорите, что существует какой-то тип URL-адреса, для которого не работают общие представления? если да, то можете привести пример? - person Dolph; 13.10.2011
comment
@Дольф: типа того. Существует определенная структура URL-адресов, для которых работают общие представления, но у меня было 2 клиента, где их представление об URL-адресе отличалось от того, что универсальное могло захватывать/доставлять. Это очень специфично для сайта. - person Peter Rowell; 13.10.2011
comment
@PeterRowell Я до сих пор не понимаю, как архитектура представления повлияет на структуру вашего URL-адреса - пример ?? - person Dolph; 15.10.2011
comment
@Dolph: конкретный пример, о котором я думал, заключался в том, что клиенту нужны URL-адреса, основанные на заголовке статьи (вложенные в псевдокатегории), даже если заголовок / категория со временем изменились. В общей архитектуре представлений нет ничего (о чем я знаю) для такого типа использования — уж точно ничего по состоянию на 10/2007, когда сайт был запущен. С тех пор у меня было еще 2 клиента с аналогичными требованиями. Это больше похоже на просмотр страниц в CMS, чем на представление даты/слага, если можно так выразиться. - person Peter Rowell; 15.10.2011
comment
@Peter Rowell: Ах, это имеет смысл! Общие представления на основе классов справятся с этим довольно изящно — просто переопределите get_object() в DetailView... и на самом деле, если слаг уникален, необходимое поведение уже встроено. Я полагаю, что общие представления, основанные на функциях, были бы жесткими в этом отношении. - person Dolph; 18.10.2011

arrow_upward
3
arrow_downward

Использовать общие представления или нет — ваша прерогатива. Это не вызовет у вас никаких проблем, хотя вы можете столкнуться с повторяющейся логикой представления. Вы можете рассмотреть возможность использования обернутых/подклассифицированных общих представлений в вашем views.py (часто вы все равно захотите их настроить), что позволит сохранить шаблон вне вашего urls.py и всех представлений в одном месте.

person zeekay    schedule 26.06.2011

arrow_upward
2
arrow_downward

В django 1.2 я использую общие представления, но внутри «обычного» представления, а не в URL-адресах, например:

#views.py
import generic_views

def my_generic_list(request):
    qs = Something.objects.filter(some arguments)
    return generic.object_list(queryset = qs, ... other stuff, usually extra_context)

таким образом (imo) представление очень простое, но может стать «настоящим» в случае изменений, в то время как urls.py остается чистым

person simone cittadini    schedule 26.06.2011