mirror of
https://github.com/django/django.git
synced 2025-08-04 19:08:28 +00:00
Removed versionadded/changed annotations for 1.9.
This commit is contained in:
parent
1915a7e5c5
commit
46a38307c2
67 changed files with 15 additions and 731 deletions
|
@ -140,10 +140,6 @@ what's passed by :class:`~django.template.backends.django.DjangoTemplates`.
|
|||
Tags and filters from built-in libraries can be used without first calling
|
||||
the :ttag:`{% load %}<load>` tag.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ``libraries`` and ``builtins`` arguments were added.
|
||||
|
||||
.. staticmethod:: Engine.get_default()
|
||||
|
||||
When a Django project configures one and only one
|
||||
|
@ -449,8 +445,6 @@ dictionary syntax::
|
|||
|
||||
.. method:: Context.setdefault(key, default=None)
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
If ``key`` is in the context, returns its value. Otherwise inserts ``key``
|
||||
with a value of ``default`` and returns ``default``.
|
||||
|
||||
|
@ -533,10 +527,6 @@ matching ``pop()`` is called.
|
|||
>>> c['foo']
|
||||
'first level'
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The ability to use ``update()`` as a context manager was added.
|
||||
|
||||
Using a ``Context`` as a stack comes in handy in :ref:`some custom template
|
||||
tags <howto-writing-custom-template-tags>`.
|
||||
|
||||
|
@ -974,11 +964,6 @@ loaders. Custom ``Loader`` classes should inherit from
|
|||
``django.template.loaders.base.Loader`` and define the ``get_contents()`` and
|
||||
``get_template_sources()`` methods.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
In previous versions of Django, custom loaders defined a single method:
|
||||
``load_template_source()``.
|
||||
|
||||
Loader methods
|
||||
--------------
|
||||
|
||||
|
@ -1073,13 +1058,6 @@ Template origin
|
|||
Templates have an ``origin`` containing attributes depending on the source
|
||||
they are loaded from.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Django used to create an origin based on
|
||||
``django.template.loader.LoaderOrigin`` or
|
||||
``django.template.base.StringOrigin``. These have been replaced by
|
||||
``django.template.base.Origin``.
|
||||
|
||||
.. class:: Origin
|
||||
|
||||
.. attribute:: name
|
||||
|
|
|
@ -296,10 +296,6 @@ Or if only some variables should be escaped, you can use::
|
|||
You can use the syntax ``{% firstof var1 var2 var3 as value %}`` to store the
|
||||
output inside a variable.
|
||||
|
||||
.. versionadded:: 1.9
|
||||
|
||||
The "as" syntax was added.
|
||||
|
||||
.. templatetag:: for
|
||||
|
||||
``for``
|
||||
|
@ -732,10 +728,6 @@ is turned off, ``{% include %}`` logs a warning to the ``django.template``
|
|||
logger with the exception that happens while rendering the included template
|
||||
and returns an empty string.
|
||||
|
||||
.. versionchanged:: 1.9
|
||||
|
||||
Template logging now includes the warning logging mentioned above.
|
||||
|
||||
.. note::
|
||||
The :ttag:`include` tag should be considered as an implementation of
|
||||
"render this subtemplate and include the HTML", not as "parse this
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue