2
장고에서보기에는 "반 다이나믹"이 있습니다. 제 경우에는 처음 방문자와 재 방문자에게 다른 내용을 제공합니다. 내보기는 응답을 렌더링하기 전에 모든 종류의 논리를 실행할 수 있지만 쿠키 (세션 데이터 또는 사용자 데이터)에 따라 다른 유형의 사용자가 다른 응답.Django의 준 동적 뷰 캐싱
나는 이것을 구현하기 위해 몇 가지 옵션을 생각하고 :
- 리디렉션 내보기에서 캐시 다른보기로. UX (URL 변경)에 영향을주기 때문에이 방법이 맘에 들지 않습니다. HTTP 서버 수준에서 캐시를 원한다면 그 접근 방식을 선택할 필요가 있다는 것을 알고 있습니다.
- 캐시 태그를 사용하여 템플릿 수준에서 캐시합니다 (전체 템플릿을 실제로 캐시 할 수 있음, 발끝까지). 그런 식으로 각 사례마다 다른 템플릿을 사용할 수 있습니다. 그것은 괜찮은 접근 방식입니다. 아마도 템플릿 엔진을 실행하는 것입니다.이 템플릿 엔진은 오히려 피해야 할 대상입니다.
- 캐싱 프레임 워크를 직접 사용하여 뷰에서 준비 HttpResponse 개체를 캐시하십시오. 실질적으로 이것은 최상의 성능을 제공하는 것처럼 들리지만, "바퀴를 재발 명"하는 것처럼 느껴집니다.
다른 아이디어? 제가 실종시킨 표준 방법 은요?
당연히 템플릿의 동적 부분은 캐시 될 수 없습니다. 필자의 경우 두 가지 옵션 만 제공하므로 완전히 동적 인 것은 아닙니다. 전체보기 캐시와 같이 완전히 캐시 할 수 있다면 기분이 좋을 것입니다. – zvikico
보기 내부에서 캐시 API *를 사용하여 쿼리 세트 등을 캐시 할 수 있으며 캐시 템플릿 태그를 사용하여 HTML의 일부를 캐시 할 수 있지만 전체보기 (데코레이터 중 하나 사용)를 캐시하면 응답 완전하게 구성된 HTML 문서를 포함하는 자체가 캐시됩니다. 따라서 페이지의 일부분을 변경해야하는 경우보기 캐싱이 해제됩니다 (인증과 같이 변경할 수있는 항목에 의존하지 않는 한). –
아마도 내 질문에 명확하지 않았습니다. 예를 들어 몇 주 전에 AWS CloudFront에서 소개 한 동적 콘텐츠 캐싱을 사용할 수 있습니다. http://aws.typepad.com/aws/2012/05/amazon-cloudfront-support-for-dynamic-content.html – zvikico