Changed docs/cache to add docs for site-wide caching, via the cache middleware

git-svn-id: http://code.djangoproject.com/svn/django/trunk@224 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/cache.txt

@@ -4,22 +4,23 @@ Django's cache framework
 
 So, you got slashdotted.  Now what?
 
-Django's cache framework gives you two methods of caching dynamic pages in
-memory or in a database: you can automatically cache the entire page, or you can manually
-cache only the pieces that are difficult to produce.
+Django's cache framework gives you three methods of caching dynamic pages in
+memory or in a database. You can cache the output of entire pages, you can
+cache only the pieces that are difficult to produce, or you can cache your
+entire site.
 
 Setting up the cache
 ====================
 
 The cache framework is split into a set of "backends" that provide different
-methods of caching data.  There's a simple single-process memory cache 
-(mostly useful as a fallback), a database-backed cache, and a memcached_
-backend (by far the fastest option if you've got the RAM).
+methods of caching data. There's a simple single-process memory cache (mostly
+useful as a fallback), a database-backed cache, and a memcached_ backend (by
+far the fastest option if you've got the RAM).
 
 Before using the cache, you'll need to tell Django which cache backend you'd
-like to use; do this by setting the ``CACHE_BACKEND`` in your settings file.
+like to use. Do this by setting the ``CACHE_BACKEND`` in your settings file.
 
-The CACHE_BACKEND setting is a quasi-URI; examples are:
+The CACHE_BACKEND setting is a quasi-URI. Examples::
 
     ==============================  ===========================================
     CACHE_BACKEND                   Explanation
@@ -37,12 +38,12 @@ The CACHE_BACKEND setting is a quasi-URI; examples are:
                                     NOT threadsafe!
     ==============================  ===========================================
 
-All caches may take arguments; these are given in query-string style.  Valid
+All caches may take arguments -- they're given in query-string style.  Valid
 arguments are:
 
     timeout
-        Default timeout, in seconds, to use for the cache.  Defaults
-        to 5 minutes (300 seconds).
+        Default timeout, in seconds, to use for the cache. Defaults to 5
+        minutes (300 seconds).
 
     max_entries
         For the simple and database backends, the maximum number of entries
@@ -65,20 +66,58 @@ For example::
 Invalid arguments are silently ignored, as are invalid values of known
 arguments.
 
-The per-page cache
+The per-site cache
 ==================
 
 Once the cache is set up, the simplest way to use the cache is to simply
-cache entire view functions.  ``django.views.decorators.cache`` defines
-a ``cache_page`` decorator that will automatically cache the view's response
-for you.  Using it couldn't be easier::
+cache your entire site. Just add ``django.middleware.cache.CacheMiddleware``
+to your ``MIDDLEWARE_CLASSES`` setting, as in this example::
+
+    MIDDLEWARE_CLASSES = (
+        "django.middleware.common.CommonMiddleware",
+        "django.middleware.cache.CacheMiddleware",
+    )
+
+Then, add the following three required settings::
+
+* ``CACHE_MIDDLEWARE_SECONDS`` -- The number of seconds each page should be
+  cached.
+* ``CACHE_MIDDLEWARE_KEY_PREFIX`` -- If the cache is shared across multiple
+  sites using the same Django installation, set this to the name of the site,
+  or some other string that is unique to this Django instance, to prevent key
+  collisions. Use an empty string if you don't care.
+* ``CACHE_MIDDLEWARE_GZIP`` -- Either ``True`` or ``False``. If this is
+  enabled, Django will gzip all content for users whose browsers support gzip
+  encoding. Using gzip adds a level of overhead to page requests, but the
+  overhead generally is cancelled out by the fact that gzipped pages are stored
+  in the cache. That means subsequent requests won't have the overhead of
+  zipping, and the cache will hold more pages because each one is smaller.
+
+Pages with GET or POST parameters won't be cached.
+
+The cache middleware also makes a few more optimizations:
+
+* Sets and deals with ``ETag`` headers.
+* Sets the ``Content-Length`` header.
+* Sets the ``Last-Modified`` header to the current date/time when a fresh
+  (uncached) version of the page is requested.
+
+It doesn't matter where in the middleware stack you put the cache middleware.
+
+The per-page cache
+==================
+
+A more granular way to use the caching framework is by caching the output of
+individual views. ``django.views.decorators.cache`` defines a ``cache_page``
+decorator that will automatically cache the view's response for you. It's easy
+to use::
 
     from django.views.decorators.cache import cache_page
 
     def slashdot_this(request):
         ...
 
-    slashdot_this = cache_page(slashdot_this, 60 * 15):
+    slashdot_this = cache_page(slashdot_this, 60 * 15)
 
 Or, using Python 2.4's decorator syntax::
 
@@ -86,19 +125,19 @@ Or, using Python 2.4's decorator syntax::
     def slashdot_this(request):
         ...
 
-This will cache the result of that view for 15 minutes (the cache timeout is
-in seconds).
+This will cache the result of that view for 15 minutes. (The cache timeout is
+in seconds.)
 
 The low-level cache API
 =======================
 
 There are times, however, that caching an entire rendered page doesn't gain
-you very much.  We often find that we only need to cache a list of object IDs
-from an intensive database query, for example.  In cases like these, you
-can use the cache API to store objects in the cache with any level of 
-granularity you like.
+you very much. The Django developers have found it's only necessary to cache a
+list of object IDs from an intensive database query, for example. In cases like
+these, you can use the cache API to store objects in the cache with any level
+of granularity you like.
 
-The cache API is almost shockingly simple::
+The cache API is simple::
 
     # the cache module exports a cache object that's automatically
     # created from the CACHE_BACKEND setting
@@ -109,31 +148,31 @@ The cache API is almost shockingly simple::
     >>> cache.get('my_key')
     'hello, world!'
 
-    # (wait 30 seconds...)
+    # (Wait 30 seconds...)
     >>> cache.get('my_key')
     None
 
-    # get can take a default argument
+    # get() can take a default argument
     >>> cache.get('my_key', 'has_expired')
     'has_expired'
 
-    # there's also a get_many interface that only hits the cache once
-    # also, note that the timeout argument is optional and defaults
-    # to what you've given in the settings file.
+    # There's also a get_many() interface that only hits the cache once.
+    # Also, note that the timeout argument is optional and defaults to what
+    # you've given in the settings file.
     >>> cache.set('a', 1)
     >>> cache.set('b', 2)
     >>> cache.set('c', 3)
+
+    # get_many() returns a dictionary with all the keys you asked for that
+    # actually exist in the cache (and haven't expired).
     >>> cache.get_many(['a', 'b', 'c'])
     {'a': 1, 'b': 2, 'c': 3}
-    # get_many returns a dict with all the keys you asked for that
-    # actually exist in the cache (and haven't expired)
 
-    # there's also a way to explicitly delete keys
+    # There's also a way to delete keys explicitly.
     >>> cache.delete('a')
 
-Really, that's the entire API!  There's very few restrictions on what you can
+Really, that's the entire API! There are very few restrictions on what you can
 use the cache for; you can store any object in the cache that can be pickled
 safely, although keys must be strings.
 
 .. _memcached: http://www.danga.com/memcached/
-