고급 템플릿

대부분의 Django 템플릿 언어와의 상호작용은 템플릿 작성자의 역할이지만, 템플릿 엔진을 사용자 정의하고 확장해야 할 수도 있습니다. 아직 하지 않은 일을 하거나, 다른 방식으로 작업을 쉽게 할 수도 있습니다.
이 장에서 Django 템플릿 시스템의 내포를 깊이 연구했다.그것은 시스템을 확장할 계획이나 작업 원리에 대해 궁금해만 한다면 알아야 할 내용을 포함한다.Django를 계속 사용할 때 보안 조치에 의심할 여지가 없는 자동 전환 기능도 포함됩니다.
템플릿 언어 검토
먼저 3장에서 설명한 몇 가지 용어를 살펴보겠습니다.

템플릿은 Django 템플릿 언어로 표시된 텍스트 문서나 일반적인 Python 문자열입니다.템플릿에는 템플릿 레이블과 변수가 포함될 수 있습니다.

템플릿 레이블은 특정 작업을 수행하는 데 사용되는 템플릿의 기호입니다.이 정의는 고의로 모호한 것이다.예를 들어 템플릿 탭은 내용을 생성하여 제어 구조(if 문장이나 for 순환)로 사용하고 데이터베이스에서 내용을 가져오거나 다른 템플릿 탭에 접근할 수 있도록 한다.템플릿 탭이 {%and%}에 둘러싸임:

{% if is_logged_in %}           
  Thanks for logging in!
  {% else %}           
  Please log in.
  {% endif %}

변수는 출력 값의 템플릿에 있는 기호입니다.가변 탭이 {{and}}에 의해 포위됨:

 My first name is {{ first_name }}. My last name is {{ last_name }}.

상하문은 템플릿에 전달되는 이름 -> 값 맵입니다. (Python 사전과 유사합니다.)

템플릿은 상하문에 있는 값으로 변수'holes'를 바꾸고 모든 템플릿 표시를 실행함으로써 상하문을 나타냅니다.

이러한 용어에 대한 기본 지식에 대한 자세한 내용은 3장을 참조하십시오.이 장의 나머지 부분에서는 템플릿 엔진을 확장하는 방법을 토론한다.우선, 간단하게 보기 위해서, 우리는 3장의 일부 내부 부분을 빠르게 훑어보았다.
RequestContext 및 컨텍스트 프로세서
템플릿을 렌더링하려면 컨텍스트가 필요합니다.이것은django일 수 있습니다.template.Context의 실례이지만 Django도 하위 클래스인 django를 가지고 있습니다.template.동작이 약간 다른 RequestContext
RequestContext는 기본적으로 HttpRequest 객체 또는 현재 로그인한 사용자의 정보와 같은 템플릿 컨텍스트에 변수를 추가합니다.
render () 단축키는 다른 상하문 실례를 명확하게 전달하지 않는 한 RequestContext를 만듭니다.예를 들어,

from django.template import loader, Context

def view_1(request):
    # ...
    t = loader.get_template('template1.html')
    c = Context({
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR'],
        'message': 'I am view 1.'
    })
    return t.render(c)

def view_2(request):
    # ...
    t = loader.get_template('template2.html')
    c = Context({
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR'],
        'message': 'I am the second view.'
    })
    return t.render(c)

(이 예시들에서render() 단축키를 일부러 사용하지 않았습니다. - 우리는 수동으로 템플릿을 불러오고 상하문 대상을 구축하고 템플릿을 보여주고 있습니다. 저는 모든 절차를 명확하게 맞추고 있습니다.)
보기마다 같은 세 가지 변수--app,user,ipaddress - 템플릿에 전달됩니다.만약 우리가 쓸데없는 것을 삭제할 수 있다면, 좋지 않겠습니까?이 문제를 해결하기 위해 RequestContext와 상하문 프로세서를 만듭니다.상하문 프로세서에서 변수를 지정할 수 있습니다. 이 변수는 상하문에서 자동으로 설정되며, 각render () 호출에서 변수를 지정할 필요가 없습니다.
문제는 템플릿을 렌더링할 때 Context 대신 RequestContext를 사용해야 한다는 점입니다.컨텍스트 프로세서를 사용하는 가장 낮은 방법은 일부 프로세서를 만들어 RequestContext에 전달하는 것입니다.위의 예는 컨텍스트 프로세서를 사용하여 작성할 수 있습니다.

from django.template import loader, RequestContext

def custom_proc(request):
    # A context processor that provides 'app', 'user' and 'ip_address'.
    return {
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR']
    }

def view_1(request):
    # ...
    t = loader.get_template('template1.html')
    c = RequestContext(request, 
                       {'message': 'I am view 1.'},  
                       processors=[custom_proc])
    return t.render(c)

def view_2(request):
    # ...
    t = loader.get_template('template2.html')
    c = RequestContext(request, 
                       {'message': 'I am the second view.'},  
                       processors=[custom_proc])
    return t.render(c)

이 코드를 살펴보겠습니다.

우선, 우리는 함수custom 을 정의합니다proc.이것은 상하문 처리기입니다. HttpRequest 대상이 필요하고 템플릿 상하문에서 사용하는 변수 사전을 되돌려줍니다.그렇습니다.

우리는 Context 대신 Request Context를 사용하기 위해 두 개의 보기 함수를 바꿨다.상하 문장의 구축에는 두 가지 다른 점이 있다.첫째, RequestContext는 첫 번째 인자가 HttpRequest 대상입니다. 첫 번째는view 함수에 전달되는 요청입니다.둘째, RequestContext는 상하문 처리 함수의 목록이나 모듈에서 사용하는 선택적인 프로세서 인자가 필요합니다.여기, 우리는customproc, 이것은 우리가 위에서 정의한 사용자 정의 프로세서입니다.

모든 보기는 상하문 구조에 app,user 또는 ip 를 포함할 필요가 없습니다.address, 왜냐하면customproc 제공.

각 뷰는 필요한 사용자 정의 템플릿 변수를 도입하는 유연성을 유지합니다.이 예에서 메시지 템플릿 변수는 보기마다 다르게 설정됩니다.제3장에서, 나는render () 단축키를 소개했는데, 이것은loader를 호출해야 한다.get_template (), 그리고 Context를 만들고 템플릿에render () 방법을 호출합니다.

상하문 프로세서의 저급한 작업을 보여주기 위해서, 위의 예는render () 를 사용하지 않았습니다.그러나 가능한 것은 - 취할 수 있는 것이다 - 렌더 ()를 통해 상하문 프로세서를 사용합니다.context 사용instance 매개 변수는 다음과 같이 이 작업을 수행합니다.

from django.shortcuts import render
from django.template import RequestContext

def custom_proc(request):
    # A context processor that provides 'app', 'user' and 'ip_address'.
    return {
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR']
    }

def view_1(request):
    # ...
    return render(request, 'template1.html',
                  {'message': 'I am view 1.'},
                  context_instance=RequestContext(
                  request, processors=[custom_proc]
                  )
    )

def view_2(request):
    # ...
    return render(request, 'template2.html', 
                  {'message': 'I am the second view.'},
                  context_instance=RequestContext(
                  request, processors=[custom_proc]
                  )
)

여기에서, 우리는 모든 보기의 템플릿 렌더링 코드를 하나의 (포장) 선으로 잘랐다.이것은 개선이지만, 이 코드의 간결성을 평가하기 위해서, 우리는 우리가 지금 거의 과잉되어 있다는 것을 인정해야만 한다.우리는 코드에 군더더기 (프로세서 호출 중) 를 추가하는 대가로 군더기 데이터 (템플릿 변수) 를 삭제했다.
항상 프로세서를 입력해야 한다면, 상하문 프로세서를 사용하면 타자 시간을 많이 절약할 수 없습니다.이 때문에 Django는 전역 상하문 프로세서에 대한 지원을 제공합니다.context_processors 설정 (settings.py에서) 은 항상 RequestContext에 적용할 상하문 프로세서를 지정합니다.이렇게 하면 RequestContext를 사용할 때마다 프로세서를 지정해야 하는 경우가 없어집니다.
기본적으로 contextprocessors가 다음과 같이 설정됩니다.

'context_processors': [
            'django.template.context_processors.debug',
            'django.template.context_processors.request',
            'django.contrib.auth.context_processors.auth',
            'django.contrib.messages.context_processors.messages',
        ],

이 설정은 우리 위의custom 을 사용합니다proc 함수와 같은 인터페이스의 호출 가능한 목록 - 요청 대상을 매개 변수로 하는 함수로 위아래 문장에 통합할 항목 사전을 되돌려줍니다.참고, context프로세스ors의 값이 문자열로 지정되었습니다. 이것은 프로세서가 Python 경로의 어딘가에 있어야 한다는 것을 의미합니다. (설정에서 인용할 수 있습니다.)
각 프로세서는 순서대로 적용됩니다.즉, 프로세서가 컨텍스트에 변수를 추가하고 두 번째 프로세서가 같은 이름의 변수를 추가하면 두 번째 프로세서가 첫 번째 프로세서를 덮어씁니다.Django는 기본적으로 활성화된 프로세서를 포함하여 여러 가지 간단한 컨텍스트 프로세서를 제공합니다.
AUTH
django.contrib.auth.context_processors.auth
이 프로세서가 활성화되어 있으면 각 RequestContext에 다음과 같은 변수가 포함됩니다.

user - 현재 로그인한 사용자를 나타내는 auth.클라이언트가 로그인하지 않은 경우 User 인스턴스(또는 AnonymousUser 인스턴스).

perms - django.contrib.auth.context_processors.PermWrapper의 인스턴스는 현재 로그인한 사용자가 소유한 권한을 나타냅니다.

DEBUG
django.template.context_processors.debug
프로세서가 활성화되어 있으면 각 RequestContext에는 두 변수가 포함됩니다. 그러나 DEBUG 설정이 True로 설정되어 있고 요청한 IP 주소(request.META ['REMOTE ADR'])만 INTERNALIPS 설정 시:

디버그 - true 템플릿에서 DEBUG 모드인지 확인할 수 있습니다.

sql_queries - {'sql':...,'time':...}사전 목록은 요청 기간 동안 발생한 각 SQL 쿼리와 소요 시간을 나타냅니다.이 목록은 조회 순서에 따라 배열되고 방문 시 생성이 지연됩니다.

국제화
django.template.context_processors.i18n
이 프로세서를 활성화하면 각 RequestContext에는 다음과 같은 두 변수가 포함됩니다.

언어 - LANGUAGES 설정의 값입니다.

LANGUAGE_CODE - request.LANGUAGE_CODE 가 있는 경우그렇지 않으면 LANGUAGECODE 설정의 값입니다.

매스컴
django.template.context_processors.media
이 프로세서를 활성화하면 각 RequestContext에 MEDIA 변수가 포함됩니다.URL, MEDIA 제공URL 설정의 값입니다.
정적
django.template.context_processors.static
이 프로세서가 활성화되어 있으면 각 RequestContext에 변수 STATIC 가 포함됩니다.URL, 제공 STATICURL 설정의 값입니다.
CSRF
django.template.context_processors.csrf
이 프로세서에 csrf 가 추가되었습니다.Token 템플릿 라벨에 필요한 표시로 크로스오버 요청의 위조를 보호합니다. (19장 참조)
청원
django.template.context_processors.request
이 프로세서를 사용하면 각 RequestContext에는 현재 HttpRequest인 변수 요청이 포함됩니다.
기별
django.contrib.messages.context_processors.messages
이 프로세서를 활성화하면 각 RequestContext에는 다음과 같은 두 변수가 포함됩니다.

메시지 - 메시지 프레임워크를 통해 설정된 메시지 목록(문자열로).

DEFAULT_MESSAGE_LEVELS - 메시지 레벨 이름과 해당 값의 매핑입니다.