你需要一段context來解析模板。 一般情況下，這是一個 django.template.Context 的實例，不過在Django中還可以用一個特殊的子類， django.template.RequestContext ，這個用起來稍微有些不同。 RequestContext 默認地在模板context中加入了一些變量，如 HttpRequest 對象或當前登錄用戶的相關信息。

當你不想在一系例模板中都明確指定一些相同的變量時，你應該使用 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_to_response() 這個快捷方法，而選擇手動載入模板，手動構造context對象然后渲染模板。 是為了能夠清晰的說明所有步驟。）

每個視圖都給模板傳入了三個相同的變量：app、user和ip_address。 如果我們把這些冗余去掉會不會更好？

創(chuàng)建 RequestContext 和 context處理器 就是為了解決這個問題。 Context處理器允許你設置一些變量，它們會在每個context中自動被設置好，而不必每次調用 render_to_response() 時都指定。 要點就是，當你渲染模板時，你要用 RequestContext 而不是 Context 。

最直接的做法是用context處理器來創(chuàng)建一些處理器并傳遞給 RequestContext 。上面的例子可以用context processors改寫如下：

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 。這是一個context處理器，它接收一個 HttpRequest 對象，然后返回一個字典，這個字典中包含了可以在模板context中使用的變量。 它就做了這么多。

    我們在這兩個視圖函數中用 RequestContext 代替了 Context 。在context對象的構建上有兩個不同點。 一， RequestContext 的第一個參數需要傳遞一個 HttpRequest 對象，就是傳遞給視圖函數的第一個參數（ request ）。二， RequestContext 有一個可選的參數 processors ，這是一個包含context處理器函數的列表或者元組。 在這里，我們傳遞了我們之前定義的處理器函數 curstom_proc 。

    每個視圖的context結構里不再包含 app 、 user 、 ip_address 等變量，因為這些由 custom_proc 函數提供了。

    每個視圖 仍然 具有很大的靈活性，可以引入我們需要的任何模板變量。 在這個例子中， message 模板變量在每個視圖中都不一樣。

 為了講解context處理器底層是如何工作的，在上面的例子中我們沒有使用 render_to_response() 。但是建議選擇 render_to_response() 作為context的處理器。這就需要用到context_instance參數：

from django.shortcuts import render_to_response
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_to_response('template1.html',
    {'message': 'I am view 1.'},
    context_instance=RequestContext(request, processors=[custom_proc]))

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

在這，我們將每個視圖的模板渲染代碼寫成了一個單行。

雖然這是一種改進，但是，請考慮一下這段代碼的簡潔性，我們現在不得不承認的是在 另外 一方面有些過分了。 我們以代碼冗余（在 processors 調用中）的代價消除了數據上的冗余（我們的模板變量）。 由于你不得不一直鍵入 processors ，所以使用context處理器并沒有減少太多的輸入量。

Django因此提供對 全局 context處理器的支持。 TEMPLATE_CONTEXT_PROCESSORS 指定了哪些context processors總是默認被使用。這樣就省去了每次使用 RequestContext 都指定 processors 的麻煩。

默認情況下， TEMPLATE_CONTEXT_PROCESSORS 設置如下：

TEMPLATE_CONTEXT_PROCESSORS = (
  'django.core.context_processors.auth',
  'django.core.context_processors.debug',
  'django.core.context_processors.i18n',
  'django.core.context_processors.media',
)

這個設置項是一個可調用函數的元組，其中的每個函數使用了和上文中我們的 custom_proc 相同的接口，它們以request對象作為參數，返回一個會被合并傳給context的字典： 接收一個request對象作為參數，返回一個包含了將被合并到context中的項的字典。

每個處理器將會按照順序應用。 也就是說如果你在第一個處理器里面向context添加了一個變量，而第二個處理器添加了同樣名字的變量，那么第二個將會覆蓋第一個。

Django提供了幾個簡單的context處理器，有些在默認情況下被啟用的。

django.core.context_processors.auth

•     user ：一個 django.contrib.auth.models.User 實例，描述了當前登錄用戶（或者一個 AnonymousUser 實例，如果客戶端沒有登錄）。
•     messages ：一個當前登錄用戶的消息列表（字符串）。 在后臺，對每一個請求，這個變量都調用 request.user.get_and_delete_messages() 方法。 這個方法收集用戶的消息然后把它們從數據庫中刪除。
•     perms ： django.core.context_processors.PermWrapper 的一個實例，包含了當前登錄用戶有哪些權限。

關于users、permissions和messages的更多內容請參考第14章。
django.core.context_processors.debug

這個處理器把調試信息發(fā)送到模板層。 如果TEMPLATE_CONTEXT_PROCESSORS包含這個處理器，每一個RequestContext將包含這些變量：

•     debug ：你設置的 DEBUG 的值（ True 或 False ）。你可以在模板里面用這個變量測試是否處在debug模式下。
•     sql_queries ：包含類似于 ``{‘sql': …, ‘time': `` 的字典的一個列表， 記錄了這個請求期間的每個SQL查詢以及查詢所耗費的時間。 這個列表是按照請求順序進行排列的。
•     System Message: WARNING/2 (<string>, line 315); backlink
•     Inline literal start-string without end-string.
• 由于調試信息比較敏感，所以這個context處理器只有當同時滿足下面兩個條件的時候才有效：
•     DEBUG 參數設置為 True 。
•     請求的ip應該包含在 INTERNAL_IPS 的設置里面。

細心的讀者可能會注意到debug模板變量的值永遠不可能為False，因為如果DEBUG是False，那么debug模板變量一開始就不會被RequestContext所包含。
django.core.context_processors.i18n

如果這個處理器啟用，每個 RequestContext 將包含下面的變量：

•     LANGUAGES ： LANGUAGES 選項的值。
•     LANGUAGE_CODE ：如果 request.LANGUAGE_CODE 存在，就等于它；否則，等同于 LANGUAGE_CODE 設置。

django.core.context_processors.request

如果啟用這個處理器，每個 RequestContext 將包含變量 request ， 也就是當前的 HttpRequest 對象。 注意這個處理器默認是不啟用的，你需要激活它。

如果你發(fā)現你的模板需要訪問當前的HttpRequest你就需要使用它:

{{ request.REMOTE_ADDR }}