diff options
| author | Adrian Holovaty <adrian@holovaty.com> | 2005-08-31 20:55:16 +0000 |
|---|---|---|
| committer | Adrian Holovaty <adrian@holovaty.com> | 2005-08-31 20:55:16 +0000 |
| commit | d74373924d053af52946aed2eda2bf0934d56f31 (patch) | |
| tree | 70ea9b9a605a875896e2c10afdae969fb6527d3b /docs/middleware.txt | |
| parent | 072a89ace2d228bcf945ca1a3966be984d0b2531 (diff) | |
Reordered stuff in docs/middleware.txt and added some small clarifications
git-svn-id: http://code.djangoproject.com/svn/django/trunk@585 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Diffstat (limited to 'docs/middleware.txt')
| -rw-r--r-- | docs/middleware.txt | 32 |
1 files changed, 16 insertions, 16 deletions
diff --git a/docs/middleware.txt b/docs/middleware.txt index e9ba29e6c1..f3901bb693 100644 --- a/docs/middleware.txt +++ b/docs/middleware.txt @@ -35,7 +35,7 @@ The default admin site has the following ``MIDDLEWARE_CLASSES`` set:: "django.middleware.common.CommonMiddleware", ) -Django applies middleware in the order it's defined in `MIDDLEWARE_CLASSES``. +Django applies middleware in the order it's defined in ``MIDDLEWARE_CLASSES``. For a regular (i.e., non-admin) Django installation, no middleware is required, but it's strongly suggested that you use ``CommonMiddleware``. For a Django @@ -77,7 +77,7 @@ Available middleware * Handles ETags based on the ``USE_ETAGS`` setting. If ``USE_ETAGS`` is set to ``True``, Django will calculate an ETag for each request by MD5-hashing the page content, and it'll take care of sending - ``Not Modified`` responses if possible. + ``Not Modified`` responses, if appropriate. * Handles flat pages. Every time Django encounters a 404 -- either within a view or as a result of no URLconfs matching -- it will check the @@ -110,21 +110,9 @@ request, before Django decides which view to execute. ``process_request()`` should return either ``None`` or an ``HttpResponse`` object. If it returns ``None``, Django will continue processing this request, executing any other middleware and, then, the appropriate view. If it returns -an ``HttpResponse`` object, Django won't bother calling any other middleware or +an ``HttpResponse`` object, Django won't bother calling ANY other middleware or the appropriate view; it'll return that ``HttpResponse``. -process_response ----------------- - -Interface: ``process_response(self, request, response)`` - -``request`` is an ``HttpRequest`` object. ``response`` is the ``HttpResponse`` -object returned by a Django view. - -``process_response()`` should return an ``HttpResponse`` object. It could alter -the given ``response``, or it could create and return a brand-new -``HttpResponse``. - process_view ------------ @@ -139,9 +127,21 @@ that will be passed to the view -- NOT including the first argument (``request`` return either ``None`` or an ``HttpResponse`` object. If it returns ``None``, Django will continue processing this request, executing any other ``process_view()`` middleware and, then, the appropriate view. If it returns an -``HttpResponse`` object, Django won't bother calling any other middleware or +``HttpResponse`` object, Django won't bother calling ANY other middleware or the appropriate view; it'll return that ``HttpResponse``. +process_response +---------------- + +Interface: ``process_response(self, request, response)`` + +``request`` is an ``HttpRequest`` object. ``response`` is the ``HttpResponse`` +object returned by a Django view. + +``process_response()`` should return an ``HttpResponse`` object. It could alter +the given ``response``, or it could create and return a brand-new +``HttpResponse``. + Guidelines ---------- |
