Логика контроллера и логика шаблонов, где вы проводите линию с нумерацией страниц?

Question

Смысл фреймворка MVC состоит в том, чтобы отделить дизайн (шаблоны) от логики (контроллеры). Однако языки шаблонов часто допускают ограниченную степень «логики проектирования». Это включает базовые операторы if, циклы, фильтрацию и т. Д.

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

{% pagify articles by 20 as pages %}

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

Это казалось оптимальным способом сделать это, потому что он позволял мне публиковать любой список в контексте; Мне не нужно было полагаться на контроллер, чтобы вернуть постраничные результаты. Но коллега утверждал, что это казалось слишком большой логикой для шаблона. Я думал, что это все еще входит в сферу логики, основанной на дизайне, поскольку страница все равно будет функционировать даже без подкачки страниц, а определение размера страницы похоже на ответственность шаблона.

Мой вопрос, это слишком много логики для шаблона? или это чистый способ справиться с этим?

Answer 1

Я всегда понимал, что представление не должно быть лишено логики. Это просто должно быть лишено какой-либо логики контроллера. Пейджинг просто связан с тем, как отображаются данные, и это именно то, что должна содержать логика представления.

Answer 2

Скажи это так; Что если вы использовали свою модель данных на другом носителе, скажем, не в Интернете, а через какое-то консольное приложение или фоновую задачу? Разве не было бы неплохо иметь возможность получать «страницы» данных через контроллер (или менеджер) вместо того, чтобы как-то полагаться на шаблон, чтобы выполнить эту работу за вас?

Хотя я, безусловно, согласен, что «внешний вид» выгружаемых данных должен обрабатываться вашим шаблоном, «акт» подкачки должен быть оставлен на усмотрение контроллера (представление Django) или даже через какой-то пользовательский менеджер. (models.Manager).

Answer 3

Представление не должно содержать бизнес-логику или логику навигации. То, что вы описываете, - это функциональность представления (избегая здесь l-слова), которую можно поместить в слой представления.

Answer 4

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

Answer 5

Я согласен с вашим коллегой; В шаблон следует вводить данные с нумерацией страниц, а не выполнять нумерацию страниц. Ключевой вопрос, я думаю, заключается в том, является ли определение размера страницы обязанностью шаблона, и я так не думаю; Я бы сказал, что это должно быть сделано на более высоком уровне.