控制器逻辑和模板逻辑,您在哪里绘制分页线？

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

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

{% pagify articles by 20 as pages %}

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

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

我的问题是,这个模板的逻辑太多了吗？或者这是一个干净的方式来处理这个？

我的理解一直是视图不应该缺乏逻辑.它应该没有任何控制器逻辑.分页只与数据的显示方式有关,这正是视图逻辑应该包含的内容.

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

虽然我当然同意分页数据的"外观"应该由您的模板处理,但是分页的"行为"应该留给控制器(Django视图)或甚至通过某种自定义管理器(模型).经理)方法.