컨트롤러 논리 및 템플릿 논리에서 페이지 매김을 사용하여 선을 그립니다.

Question

MVC 프레임 워크의 핵심은 디자인 (템플릿)을 로직 (컨트롤러)과 분리하는 것입니다. 그러나 템플릿 언어는 제한된 수준의 "디자인 논리"를 발생시킬 수 있습니다. 여기에는 기본적인 if 문, 루프, 필터링 등이 포함됩니다.

모든 목록이나 QuerySet을 가져 와서 "페이지 설정"할 수있는 장고 템플릿 태그를 만들었습니다. 지정된 페이지 크기를 기반으로 목록을 페이지로 분할 한 다음 페이지를 컨텍스트에 추가합니다.

{% pagify articles by 20 as pages %} 

난 후 별도의 페이지를 반복하고 나는 그것을 필요로 어디든지 페이지의 좋은 목록을 생성합니다 포함 호출 할 수 있습니다 : 다음과 같이 사용이다.

이것은 내가 컨텍스트에서 임의의 목록을 페이지 할 수있게하기 때문에 최적의 방법이라고 생각됩니다. 페이징 된 결과를 반환하기 위해 컨트롤러에 의존 할 필요가 없었습니다. 그러나 동료는 이것이 템플릿에 너무 많은 논리처럼 보인다고 주장했다. 페이지가 페이징 없이도 여전히 작동하고 페이지 크기를 결정하는 것이 템플릿 책임처럼 느껴지기 때문에 이것이 여전히 디자인 기반 논리 영역에 해당한다고 생각했습니다.

내 질문에 템플릿에 너무 많은 논리가 있습니까? 아니면 이것을 처리 할 수있는 깨끗한 방법입니까?

Answer 1

이렇게하면됩니다. 웹에서가 아니라 콘솔 기반 애플리케이션이나 백그라운드 작업을 통해 다른 미디어에서 데이터 모델을 사용한다면 어떨까요? 컨트롤러 (또는 관리자)를 통해 데이터의 "페이지"를 얻을 수있는 것이 좋지 않을까요? 템플릿 대신이 작업을 수행해야합니까?

페이징 된 데이터의 "보기"가 템플릿에 의해 처리되어야한다는 것에 확실히 동의하지만 페이징의 "행위"는 컨트롤러 (장고보기) 또는 일부 종류의 사용자 지정 manager (models.Manager) 메소드를 호출합니다.

Answer 2

보기에는 비즈니스 논리 또는 탐색 논리가 포함되어서는 안됩니다. 당신이 설명하는 것은 뷰 레이어에 배치 할 수있는 프리젠 테이션 기능입니다 (여기에서주의를 기울이지 마십시오).

Answer 3

나는 귀하의 동료와 동의합니다. 템플릿은 페이지 매김을 수행하는 것이 아니라 페이지가 매겨진 데이터로 공급되어야합니다. 핵심 질문은 페이지 크기를 결정하는 것이 기본 임무인지 아닌지를 생각하는 것입니다. 나는 그것이 더 높은 차원에서 다루어 져야한다고 말하고 싶다.

Answer 4

보기가 논리가없는 것으로 가정되는 것은 항상 내 이해입니다. 그것은 단지 컨트롤러 로직이 없다고 가정합니다. 페이징은 뷰 논리가 포함해야하는 것과 정확히 일치하는 데이터가 표시되는 방식과 관련이 있습니다.

Answer 5

비슷한 템플릿 태그를 제공하는 django-pagination을 확인하시기 바랍니다.