From 9a9e2730bc9c5a5dbf087db7e5a24e8300bb7ea9 Mon Sep 17 00:00:00 2001 From: Joseph Kocherhans Date: Fri, 13 Jan 2006 18:27:40 +0000 Subject: [PATCH] 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 | 14 +++++++------- docs/flatpages.txt | 4 ++-- docs/generic_views.txt | 8 ++++---- docs/i18n.txt | 4 ++-- docs/settings.txt | 6 +++--- docs/templates_python.txt | 18 +++++++++--------- 6 files changed, 27 insertions(+), 27 deletions(-) diff --git a/docs/authentication.txt b/docs/authentication.txt index 2a7076ff78..7780d668a5 100644 --- a/docs/authentication.txt +++ b/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 {% 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 diff --git a/docs/flatpages.txt b/docs/flatpages.txt index 5c0520dae0..863cefeff9 100644 --- a/docs/flatpages.txt +++ b/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 diff --git a/docs/generic_views.txt b/docs/generic_views.txt index 35b0532d16..cbb1aa8cf6 100644 --- a/docs/generic_views.txt +++ b/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 - `DjangoContext docs`_ + ``RequestContext`` of this view's template. See the + `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: diff --git a/docs/i18n.txt b/docs/i18n.txt index 9a3566edf9..9e7cccad8b 100644 --- a/docs/i18n.txt +++ b/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 %} diff --git a/docs/settings.txt b/docs/settings.txt index 60e75f7969..5d447e5415 100644 --- a/docs/settings.txt +++ b/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`_. diff --git a/docs/templates_python.txt b/docs/templates_python.txt index e01d48304c..71d94dbb5a 100644 --- a/docs/templates_python.txt +++ b/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,