From d74373924d053af52946aed2eda2bf0934d56f31 Mon Sep 17 00:00:00 2001
From: Adrian Holovaty <adrian@holovaty.com>
Date: Wed, 31 Aug 2005 20:55:16 +0000
Subject: [PATCH] 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
---
 docs/middleware.txt | 32 ++++++++++++++++----------------
 1 file 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
 ----------