Question

MVC框架的重点是将设计（模板）与逻辑（控制器）分开。但是，模板语言通常会提供有限程度的“设计逻辑”。这包括基本的if语句，循环，过滤等。

我创建了一个Django模板标记，可以使用任何列表或QuerySet并“pagify”它。它根据指定的页面大小将列表拆分为页面，然后将页面添加到上下文中。用法如下：

{% pagify articles by 20 as pages %}

然后，我可以调用一个单独的include来迭代页面，并在我需要的地方生成一个很好的页面列表。

这似乎是一种最佳方式，因为它允许我在上下文中分页任何列表;我没有必要依靠控制器来返回分页结果。但是一位同事认为，这似乎是模板的逻辑。我认为这仍然属于基于设计的逻辑领域，因为即使没有分页，页面仍然可以正常工作，并且确定页面大小感觉就像模板的责任。

我的问题是，模板的逻辑是否过多？或者这是一个干净的方式处理这个？

Answer 1

我一直认为这种观点不应该缺乏逻辑。它应该没有任何控制器逻辑。分页只与数据的显示方式有关，这正是视图逻辑应该包含的内容。

Answer 2

这样说吧;如果您在其他媒体中使用您的数据模型，比如说，不是在网络上，而是通过某种基于控制台的应用程序或后台任务，该怎么办？通过控制器（或管理器）获取数据的“页面”而不是以某种方式依靠模板为您完成这项工作，这不是很好吗？

虽然我当然同意分页数据的“外观”应该由您的模板处理，但是分页的“行为”应该留给控制器（Django视图）或甚至通过某种自定义管理器（models.Manager）方法。

Answer 3

视图不应包含业务逻辑或导航逻辑。你所描述的是演示功能（在这里小心避免使用l字），它可以放在视图层中。

Answer 4

您可能需要查看django-pagination，它提供了类似的模板标记。

Answer 5

我同意你的同事;模板应该输入分页数据而不是执行分页。我认为关键问题是确定页面大小是否是模板职责，我不这么认为;我会说它应该在更高的层次上处理。