Fixed #14038 -- Added information to release notes and version changed|added markers to documentation additions for the new template loeaders API introduced in version 1.2. Thanks 3point2 for the report.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@15309 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Ramiro Morales 2011-01-25 15:42:24 +00:00
parent 5d2ea792ec
commit f81d4ba5b3
3 changed files with 43 additions and 2 deletions

View File

@ -1743,6 +1743,12 @@ used instead of a string. The first item in the tuple should be the ``Loader``'s
module, subsequent items are passed to the ``Loader`` during initialization. See
:doc:`/ref/templates/api`.
.. versionchanged:: 1.2
The class-based API for template loaders was introduced in Django 1.2
although the ``TEMPLATE_LOADERS`` setting will accept strings that specify
function-based loaders until compatibility with them is completely removed in
Django 1.4.
.. setting:: TEMPLATE_STRING_IF_INVALID
TEMPLATE_STRING_IF_INVALID

View File

@ -630,8 +630,13 @@ sources.
Some of these other loaders are disabled by default, but you can activate them
by editing your :setting:`TEMPLATE_LOADERS` setting. :setting:`TEMPLATE_LOADERS`
should be a tuple of strings, where each string represents a template loader.
Here are the template loaders that come with Django:
should be a tuple of strings, where each string represents a template loader
class. Here are the template loaders that come with Django:
.. versionchanged:: 1.2
Template loaders were based on callables (usually functions) before Django
1.2, starting with the 1.2 release there is a new class-based API, all the
loaders described below implement this new API.
``django.template.loaders.filesystem.Loader``
Loads templates from the filesystem, according to :setting:`TEMPLATE_DIRS`.

View File

@ -256,6 +256,29 @@ As a side effect, it is now much easier to support non-Django template
languages. For more details, see the :ref:`notes on supporting
non-Django template languages<topic-template-alternate-language>`.
Class-based template loaders
----------------------------
As part of the changes made to introduce `Template caching`_ and following
a general trend in Django, the template loaders API has been modified
to use template loading mechanisms that are encapsulated in Python classes as
opposed to functions, the only method available until Django 1.1.
All the template loaders :ref:`shipped with Django <template-loaders>` have
been ported to the new API but they still implement the function-based API and
the template core machinery still accepts function-based loaders (builtin or
third party) so there is no immediate need to modify your
:setting:`TEMPLATE_LOADERS` setting in existing projects, things will keep
working if you leave it untouched up to and including the Django 1.3 release.
If you have developed your own custom template loaders we suggest to consider
porting them to a class-based implementation because the code for backwards
compatibility with function-based loaders starts its deprecation process in
Django 1.2 and will be removed in Django 1.4. There is a description of the
API these loader classes must implement :ref:`here
<topic-template-alternate-language>` and you can also examine the source code
of the loaders shipped with Django.
Natural keys in fixtures
------------------------
@ -1137,3 +1160,10 @@ Language code ``no``
The currently used language code for Norwegian Bokmål ``no`` is being
replaced by the more common language code ``nb``.
Function-based template loaders
-------------------------------
Django 1.2 changes the template loading mechanism to use a class-based
approach. Old style function-based template loaders will still work, but should
be updated to use the new :ref:`class-based template loaders
<topic-template-alternate-language>`.