magic-removal: Updated docs to reflect move/rename of DjangoContext.

git-svn-id: http://code.djangoproject.com/svn/django/branches/magic-removal@1951 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/authentication.txt

@@ -435,16 +435,16 @@ Authentication data in templates
 ================================
 
 The currently logged-in user and his/her permissions are made available in the
-`template context`_ when you use ``DjangoContext``.
+`template context`_ when you use ``RequestContext``.
 
 .. admonition:: Technicality
 
    Technically, these variables are only made available in the template context
-   if you use ``DjangoContext`` *and* your ``TEMPLATE_CONTEXT_PROCESSORS``
+   if you use ``RequestContext`` *and* your ``TEMPLATE_CONTEXT_PROCESSORS``
    setting contains ``"django.core.context_processors.auth"``, which is default.
-   For more, see the `DjangoContext docs`_.
+   For more, see the `RequestContext docs`_.
 
-   .. _DjangoContext docs: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-djangocontext
+   .. _RequestContext docs: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-djangocontext
 
 Users
 -----
@@ -533,9 +533,9 @@ a playlist::
         # Create the playlist with the given songs.
         # ...
         request.user.add_message("Your playlist was added successfully.")
-        return render_to_response("playlists/create", context_instance=DjangoContext(request))
+        return render_to_response("playlists/create", context_instance=RequestContext(request))
 
-When you use ``DjangoContext``, the currently logged-in user and his/her
+When you use ``RequestContext``, the currently logged-in user and his/her
 messages are made available in the `template context`_ as the template variable
 ``{{ messages }}``. Here's an example of template code that displays messages::
 
@@ -547,7 +547,7 @@ messages are made available in the `template context`_ as the template variable
     </ul>
     {% endif %}
 
-Note that ``DjangoContext`` calls ``get_and_delete_messages`` behind the
+Note that ``RequestContext`` calls ``get_and_delete_messages`` behind the
 scenes, so any messages will be deleted even if you don't display them.
 
 Finally, note that this messages framework only works with users in the user

docs/flatpages.txt

@@ -49,7 +49,7 @@ If it finds a match, it follows this algorithm:
     * If the flatpage has a custom template, it loads that template. Otherwise,
       it loads the template ``flatpages/default``.
     * It passes that template a single context variable, ``flatpage``, which is
-      the flatpage object. It uses DjangoContext_ in rendering the template.
+      the flatpage object. It uses RequestContext_ in rendering the template.
 
 If it doesn't find a match, the request continues to be processed as usual.
 
@@ -63,7 +63,7 @@ resort.
 For more on middleware, read the `middleware docs`_.
 
 .. _SITE_ID: http://www.djangoproject.com/documentation/settings/#site-id
-.. _DjangoContext: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-djangocontext
+.. _RequestContext: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-djangocontext
 .. _middleware docs: http://www.djangoproject.com/documentation/middleware/
 
 How to add, change and delete flatpages

docs/generic_views.txt

@@ -121,16 +121,16 @@ arguments:
                              template's context.
 
     ``processors``           A tuple of processors to apply to the
-                             ``DjangoContext`` of this view's template. See the
+                             ``RequestContext`` of this view's template. See the
-                             `DjangoContext docs`_
+                             `RequestContext docs`_
     =======================  ==================================================
 
 .. _database API docs: http://www.djangoproject.com/documentation/db_api/
-.. _DjangoContext docs: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-djangocontext
+.. _RequestContext docs: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-djangocontext
 
 The date-based generic functions are:
 
-``archive_index``
+``archive_index``RequestContext
     A top-level index page showing the "latest" objects.
 
     Takes the following optional arguments:

docs/i18n.txt

@@ -224,14 +224,14 @@ To pluralize, specify both the singular and plural forms with the
 Internally, all block and inline translations use the appropriate
 ``gettext`` / ``ngettext`` call.
 
-Each ``DjangoContext`` has access to two translation-specific variables:
+Each ``RequestContext`` has access to two translation-specific variables:
 
     * ``LANGUAGES`` is a list of tuples in which the first element is the
       language code and the second is the language name (in that language).
     * ``LANGUAGE_CODE`` is the current user's preferred language, as a string.
       Example: ``en-us``. (See "How language preference is discovered", below.)
 
-If you don't use the ``DjangoContext`` extension, you can get those values with
+If you don't use the ``RequestContext`` extension, you can get those values with
 two tags::
 
     {% get_current_language as LANGUAGE_CODE %}

docs/settings.txt

@@ -463,7 +463,7 @@ MIDDLEWARE_CLASSES
 
 Default::
 
-    ("django.contrib.sessions.middleware.SessionMiddleware",
+    ("django.middleware.sessions.SessionMiddleware",
      "django.middleware.common.CommonMiddleware",
      "django.middleware.doc.XViewMiddleware")
 
@@ -555,7 +555,7 @@ Default::
     "django.core.context_processors.debug",
     "django.core.context_processors.i18n")
 
-A tuple of callables that are used to populate the context in ``DjangoContext``.
+A tuple of callables that are used to populate the context in ``RequestContext``.
 These callables take a request object as their argument and return a dictionary
 of items to be merged into the context.
 
@@ -595,7 +595,7 @@ templates. See the `template documentation`_.
 TEMPLATE_LOADERS
 ----------------
 
-Default: ``('django.core.template.loaders.filesystem.load_template_source',)``
+Default: ``('django.template.loaders.filesystem.load_template_source',)``
 
 A tuple of callables (as strings) that know how to import templates from
 various sources. See the `template documentation`_.

docs/templates_python.txt

@@ -241,15 +241,15 @@ If you ``pop()`` too much, it'll raise
 Using a ``Context`` as a stack comes in handy in some custom template tags, as
 you'll see below.
 
-Subclassing Context: DjangoContext
+Subclassing Context: RequestContext
 ----------------------------------
 
 Django comes with a special ``Context`` class,
-``django.core.extensions.DjangoContext``, that acts slightly differently than
+``django.template.RequestContext``, that acts slightly differently than
 the normal ``django.template.Context``. The first difference is that takes
 an `HttpRequest object`_ as its first argument. For example::
 
-    c = DjangoContext(request, {
+    c = RequestContext(request, {
         'foo': 'bar',
     }
 
@@ -269,16 +269,16 @@ variable to the context and a second processor adds a variable with the same
 name, the second will override the first. The default processors are explained
 below.
 
-Also, you can give ``DjangoContext`` a list of additional processors, using the
+Also, you can give ``RequestContext`` a list of additional processors, using the
 optional, third positional argument, ``processors``. In this example, the
-``DjangoContext`` instance gets a ``ip_address`` variable::
+``RequestContext`` instance gets a ``ip_address`` variable::
 
     def ip_address_processor(request):
         return {'ip_address': request.META['REMOTE_ADDR']}
 
     def some_view(request):
         # ...
-        return DjangoContext({
+        return RequestContext({
             'foo': 'bar',
         }, [ip_address_processor])
 
@@ -291,7 +291,7 @@ django.core.context_processors.auth
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If ``TEMPLATE_CONTEXT_PROCESSORS`` contains this processor, every
-``DjangoContext`` will contain these three variables:
+``RequestContext`` will contain these three variables:
 
     * ``user`` -- An ``auth.User`` instance representing the currently
       logged-in user (or an ``AnonymousUser`` instance, if the client isn't
@@ -309,7 +309,7 @@ django.core.context_processors.debug
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If ``TEMPLATE_CONTEXT_PROCESSORS`` contains this processor, every
-``DjangoContext`` will contain these two variables -- but only if your
+``RequestContext`` will contain these two variables -- but only if your
 ``DEBUG`` setting is set to ``True`` and the request's IP address
 (``request.META['REMOTE_ADDR']``) is in the ``INTERNAL_IPS`` setting:
 
@@ -323,7 +323,7 @@ django.core.context_processors.i18n
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If ``TEMPLATE_CONTEXT_PROCESSORS`` contains this processor, every
-``DjangoContext`` will contain these two variables:
+``RequestContext`` will contain these two variables:
 
     * ``LANGUAGES`` -- The value of the `LANGUAGES setting`_.
     * ``LANGUAGE_CODE`` -- ``request.LANGUAGE_CODE``, if it exists. Otherwise,