mirror of
https://github.com/django/django.git
synced 2025-07-24 13:44:32 +00:00
Adapted uses of versionchanged/versionadded to the new form.
Refs #20104.
This commit is contained in:
parent
1ddeeb5b8e
commit
78c842a323
48 changed files with 206 additions and 148 deletions
|
@ -105,6 +105,7 @@ TemplateView
|
|||
in the URL.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The context used to be populated with a ``{{ params }}`` dictionary of
|
||||
the parameters captured in the URL. Now those parameters are first-level
|
||||
context variables.
|
||||
|
|
|
@ -142,7 +142,7 @@ YearArchiveView
|
|||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Previously, this returned a string.
|
||||
Previously, this returned a string.
|
||||
|
||||
* ``next_year``: A :class:`~datetime.date` object
|
||||
representing the first day of the next year, according to
|
||||
|
|
|
@ -330,5 +330,6 @@ BaseDateListView
|
|||
:meth:`QuerySet.dates()<django.db.models.query.QuerySet.dates>`.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The ``ordering`` parameter was added, and the default order was
|
||||
changed to ascending.
|
||||
|
|
|
@ -206,10 +206,10 @@ ProcessFormView
|
|||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
``success_url`` may contain dictionary string formatting, which
|
||||
will be interpolated against the object's field attributes. For
|
||||
example, you could use ``success_url="/parent/%(parent_id)s/"`` to
|
||||
redirect to a URL composed out of the ``parent_id`` field on a model.
|
||||
``success_url`` may contain dictionary string formatting, which
|
||||
will be interpolated against the object's field attributes. For
|
||||
example, you could use ``success_url="/parent/%(parent_id)s/"`` to
|
||||
redirect to a URL composed out of the ``parent_id`` field on a model.
|
||||
|
||||
.. method:: get_success_url()
|
||||
|
||||
|
|
|
@ -67,7 +67,6 @@ TemplateResponseMixin
|
|||
.. attribute:: content_type
|
||||
|
||||
.. versionadded:: 1.5
|
||||
The ``content_type`` attribute was added.
|
||||
|
||||
The content type to use for the response. ``content_type`` is passed
|
||||
as a keyword argument to ``response_class``. Default is ``None`` --
|
||||
|
|
|
@ -62,6 +62,7 @@ To set the same ``X-Frame-Options`` value for all responses in your site, put
|
|||
)
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
This middleware is enabled in the settings file generated by
|
||||
:djadmin:`startproject`.
|
||||
|
||||
|
|
|
@ -18,6 +18,7 @@ The admin is enabled in the default project template used by
|
|||
:djadmin:`startproject`.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In previous versions, the admin wasn't enabled by default.
|
||||
|
||||
For reference, here are the requirements:
|
||||
|
@ -1341,6 +1342,7 @@ templates used by the :class:`ModelAdmin` views:
|
|||
return qs.filter(author=request.user)
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``get_queryset`` method was previously named ``queryset``.
|
||||
|
||||
.. method:: ModelAdmin.message_user(request, message, level=messages.INFO, extra_tags='', fail_silently=False)
|
||||
|
@ -1348,7 +1350,9 @@ templates used by the :class:`ModelAdmin` views:
|
|||
Sends a message to the user using the :mod:`django.contrib.messages`
|
||||
backend. See the :ref:`custom ModelAdmin example <custom-admin-action>`.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Keyword arguments were added in Django 1.5.
|
||||
|
||||
Keyword arguments allow you to change the message level, add extra CSS
|
||||
tags, or fail silently if the ``contrib.messages`` framework is not
|
||||
|
@ -1451,6 +1455,7 @@ in your own admin JavaScript without including a second copy, you can use the
|
|||
``django.jQuery`` object on changelist and add/edit views.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The embedded jQuery has been upgraded from 1.4.2 to 1.9.1.
|
||||
|
||||
The :class:`ModelAdmin` class requires jQuery by default, so there is no need
|
||||
|
|
|
@ -234,18 +234,18 @@ lookup::
|
|||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Prior to Django 1.5,
|
||||
:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_model` and
|
||||
:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_models`
|
||||
always returned the :class:`~django.contrib.contenttypes.models.ContentType`
|
||||
associated with the concrete model of the specified one(s). That means there
|
||||
was no way to retrieve the
|
||||
:class:`~django.contrib.contenttypes.models.ContentType` of a proxy model
|
||||
using those methods. As of Django 1.5 you can now pass a boolean flag –
|
||||
``for_concrete_model`` and ``for_concrete_models`` respectively – to specify
|
||||
wether or not you want to retrieve the
|
||||
:class:`~django.contrib.contenttypes.models.ContentType` for the concrete or
|
||||
direct model.
|
||||
Prior to Django 1.5,
|
||||
:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_model` and
|
||||
:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_models`
|
||||
always returned the :class:`~django.contrib.contenttypes.models.ContentType`
|
||||
associated with the concrete model of the specified one(s). That means there
|
||||
was no way to retrieve the
|
||||
:class:`~django.contrib.contenttypes.models.ContentType` of a proxy model
|
||||
using those methods. As of Django 1.5 you can now pass a boolean flag –
|
||||
``for_concrete_model`` and ``for_concrete_models`` respectively – to specify
|
||||
wether or not you want to retrieve the
|
||||
:class:`~django.contrib.contenttypes.models.ContentType` for the concrete or
|
||||
direct model.
|
||||
|
||||
Generic relations
|
||||
=================
|
||||
|
|
|
@ -950,6 +950,7 @@ __ http://geohash.org/
|
|||
*Availability*: PostGIS, SpatiaLite
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
``geojson`` support for Spatialite > 3.0 has been added.
|
||||
|
||||
Attaches a ``geojson`` attribute to every model in the queryset that contains the
|
||||
|
|
|
@ -252,6 +252,7 @@ Enabling the sites framework
|
|||
============================
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
In previous versions, the sites framework was enabled by default.
|
||||
|
||||
To enable the sites framework, follow these steps:
|
||||
|
|
|
@ -182,6 +182,7 @@ Django supports MySQL 5.0.3 and higher.
|
|||
data on all database schema. Django's ``inspectdb`` feature uses it.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The minimum version requirement of MySQL 5.0.3 was set in Django 1.5.
|
||||
|
||||
Django expects the database to support Unicode (UTF-8 encoding) and delegates to
|
||||
|
|
|
@ -98,6 +98,7 @@ Can be run as a cronjob or directly to clean out old data from the database
|
|||
(only expired sessions at the moment).
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
:djadmin:`cleanup` is deprecated. Use :djadmin:`clearsessions` instead.
|
||||
|
||||
compilemessages
|
||||
|
@ -122,7 +123,7 @@ Example usage::
|
|||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Added the ability to specify multiple locales.
|
||||
Added the ability to specify multiple locales.
|
||||
|
||||
createcachetable
|
||||
----------------
|
||||
|
@ -173,6 +174,7 @@ The :djadminopt:`--all` option may be provided to display all settings, even
|
|||
if they have Django's default value. Such settings are prefixed by ``"###"``.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The :djadminopt:`--all` option was added.
|
||||
|
||||
dumpdata <appname appname appname.Model ...>
|
||||
|
@ -307,8 +309,8 @@ database to introspect.
|
|||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The behavior by which introspected models are created as unmanaged ones is new
|
||||
in Django 1.6.
|
||||
The behavior by which introspected models are created as unmanaged ones is new
|
||||
in Django 1.6.
|
||||
|
||||
loaddata <fixture fixture ...>
|
||||
------------------------------
|
||||
|
@ -467,7 +469,7 @@ You can also use commas to separate multiple locales::
|
|||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Added the ability to specify multiple locales.
|
||||
Added the ability to specify multiple locales.
|
||||
|
||||
.. django-admin-option:: --domain
|
||||
|
||||
|
@ -778,8 +780,6 @@ use the ``--plain`` option, like so::
|
|||
|
||||
django-admin.py shell --plain
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
If you would like to specify either IPython or bpython as your interpreter if
|
||||
you have both installed you can specify an alternative interpreter interface
|
||||
with the ``-i`` or ``--interface`` options like so:
|
||||
|
@ -807,9 +807,13 @@ behavior you can use the ``--no-startup`` option. e.g.::
|
|||
|
||||
django-admin.py shell --plain --no-startup
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
The ``--interface`` option was added in Django 1.5.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
The ``--no-startup`` option was added in Django 1.6.
|
||||
The ``--no-startup`` option was added in Django 1.6.
|
||||
|
||||
sql <appname appname ...>
|
||||
-------------------------
|
||||
|
@ -1353,6 +1357,7 @@ for any other exception. If you specify ``--traceback``, ``django-admin.py``
|
|||
will also output a full stack trace when a ``CommandError`` is raised.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previously, Django didn't show a full stack trace by default for exceptions
|
||||
other than ``CommandError``.
|
||||
|
||||
|
|
|
@ -138,6 +138,7 @@ the underlying database exceptions. See :pep:`249`, the Python Database API
|
|||
Specification v2.0, for further information.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Previous version of Django only wrapped ``DatabaseError`` and
|
||||
``IntegrityError``.
|
||||
|
||||
|
|
|
@ -468,6 +468,7 @@ For each field, we describe the default widget used if you don't specify
|
|||
``%(limit_value)s``, which will be substituted by the appropriate limit.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Similarly, the ``max_digits``, ``max_decimal_places`` and
|
||||
``max_whole_digits`` error messages may contain ``%(max)s``.
|
||||
|
||||
|
@ -1014,10 +1015,12 @@ objects (in the case of ``ModelMultipleChoiceField``) into the
|
|||
``invalid_pk_value``
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The empty and normalized values were changed to be consistently
|
||||
``QuerySets`` instead of ``[]`` and ``QuerySet`` respectively.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``invalid_choice`` message may contain ``%(value)s`` and the
|
||||
``invalid_pk_value`` message may contain ``%(pk)s``, which will be
|
||||
substituted by the appropriate values.
|
||||
|
|
|
@ -42,7 +42,7 @@ Model Form Functions
|
|||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``widgets`` and the ``validate_max`` parameters were added.
|
||||
The ``widgets`` and the ``validate_max`` parameters were added.
|
||||
|
||||
.. function:: inlineformset_factory(parent_model, model, form=ModelForm, formset=BaseInlineFormSet, fk_name=None, fields=None, exclude=None, extra=3, can_order=False, can_delete=True, max_num=None, formfield_callback=None, widgets=None, validate_max=False)
|
||||
|
||||
|
@ -57,4 +57,4 @@ Model Form Functions
|
|||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The ``widgets`` and the ``validate_max`` parameters were added.
|
||||
The ``widgets`` and the ``validate_max`` parameters were added.
|
||||
|
|
|
@ -359,7 +359,7 @@ considering aren't valid, we must remember to remove them from the
|
|||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Django used to remove the ``cleaned_data`` attribute entirely if there were
|
||||
any errors in the form. Since version 1.5, ``cleaned_data`` is present even if
|
||||
the form doesn't validate, but it contains only field values that did
|
||||
validate.
|
||||
Django used to remove the ``cleaned_data`` attribute entirely if there were
|
||||
any errors in the form. Since version 1.5, ``cleaned_data`` is present even if
|
||||
the form doesn't validate, but it contains only field values that did
|
||||
validate.
|
||||
|
|
|
@ -522,6 +522,7 @@ Selector and checkbox widgets
|
|||
``True`` if the checkbox should be checked for that value.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Exceptions from ``check_test`` used to be silenced by its caller,
|
||||
this is no longer the case, they will propagate upwards.
|
||||
|
||||
|
|
|
@ -206,6 +206,7 @@ Transaction middleware
|
|||
.. class:: TransactionMiddleware
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
``TransactionMiddleware`` is deprecated. The documentation of transactions
|
||||
contains :ref:`upgrade instructions <transactions-upgrading-from-1.5>`.
|
||||
|
||||
|
|
|
@ -378,6 +378,7 @@ If you need to accept :attr:`~Field.null` values then use
|
|||
:class:`NullBooleanField` instead.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
The default value of ``BooleanField`` was changed from ``False`` to
|
||||
``None`` when :attr:`Field.default` isn't defined.
|
||||
|
||||
|
@ -956,8 +957,8 @@ Like all :class:`CharField` subclasses, :class:`URLField` takes the optional
|
|||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
The current value of the field will be displayed as a clickable link above the
|
||||
input widget.
|
||||
The current value of the field will be displayed as a clickable link above the
|
||||
input widget.
|
||||
|
||||
|
||||
Relationship fields
|
||||
|
|
|
@ -297,8 +297,9 @@ follows this algorithm:
|
|||
didn't update anything, Django executes an ``INSERT``.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
Previously Django used ``SELECT`` - if not found ``INSERT`` else ``UPDATE``
|
||||
algorithm. The old algorithm resulted in one more query in ``UPDATE`` case.
|
||||
|
||||
Previously Django used ``SELECT`` - if not found ``INSERT`` else ``UPDATE``
|
||||
algorithm. The old algorithm resulted in one more query in ``UPDATE`` case.
|
||||
|
||||
The one gotcha here is that you should be careful not to specify a primary-key
|
||||
value explicitly when saving new objects, if you cannot guarantee the
|
||||
|
|
|
@ -554,11 +554,13 @@ Returns a ``DateQuerySet`` — a ``QuerySet`` that evaluates to a list of
|
|||
particular kind within the contents of the ``QuerySet``.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
``dates`` used to return a list of :class:`datetime.datetime` objects.
|
||||
|
||||
``field`` should be the name of a ``DateField`` of your model.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
``dates`` used to accept operating on a ``DateTimeField``.
|
||||
|
||||
``kind`` should be either ``"year"``, ``"month"`` or ``"day"``. Each
|
||||
|
@ -1121,11 +1123,11 @@ to ``defer()``::
|
|||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Some fields in a model won't be deferred, even if you ask for them. You can
|
||||
never defer the loading of the primary key. If you are using
|
||||
:meth:`select_related()` to retrieve related models, you shouldn't defer the
|
||||
loading of the field that connects from the primary model to the related
|
||||
one, doing so will result in an error.
|
||||
Some fields in a model won't be deferred, even if you ask for them. You can
|
||||
never defer the loading of the primary key. If you are using
|
||||
:meth:`select_related()` to retrieve related models, you shouldn't defer the
|
||||
loading of the field that connects from the primary model to the related
|
||||
one, doing so will result in an error.
|
||||
|
||||
.. note::
|
||||
|
||||
|
@ -1193,20 +1195,20 @@ logically::
|
|||
# existing set of fields).
|
||||
Entry.objects.defer("body").only("headline", "body")
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
All of the cautions in the note for the :meth:`defer` documentation apply to
|
||||
``only()`` as well. Use it cautiously and only after exhausting your other
|
||||
options. Also note that using :meth:`only` and omitting a field requested
|
||||
using :meth:`select_related` is an error as well.
|
||||
options.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
.. note::
|
||||
Using :meth:`only` and omitting a field requested using
|
||||
:meth:`select_related` is an error as well.
|
||||
|
||||
When calling :meth:`~django.db.models.Model.save()` for instances with
|
||||
deferred fields, only the loaded fields will be saved. See
|
||||
:meth:`~django.db.models.Model.save()` for more details.
|
||||
.. note::
|
||||
|
||||
When calling :meth:`~django.db.models.Model.save()` for instances with
|
||||
deferred fields, only the loaded fields will be saved. See
|
||||
:meth:`~django.db.models.Model.save()` for more details.
|
||||
|
||||
using
|
||||
~~~~~
|
||||
|
@ -1424,6 +1426,7 @@ query. The default is to create all objects in one batch, except for SQLite
|
|||
where the default is such that at maximum 999 variables per query is used.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
The ``batch_size`` parameter was added in version 1.5.
|
||||
|
||||
count
|
||||
|
@ -1725,7 +1728,8 @@ methods on your models. It does, however, emit the
|
|||
(including cascaded deletions).
|
||||
|
||||
.. versionadded:: 1.5
|
||||
Allow fast-path deletion of objects
|
||||
|
||||
Allow fast-path deletion of objects.
|
||||
|
||||
Django needs to fetch objects into memory to send signals and handle cascades.
|
||||
However, if there are no cascades and no signals, then Django may take a
|
||||
|
|
|
@ -94,6 +94,7 @@ All attributes should be considered read-only, unless stated otherwise below.
|
|||
:attr:`HttpRequest.body` attribute instead.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Before Django 1.5, HttpRequest.POST contained non-form data.
|
||||
|
||||
It's possible that a request can come in via POST with an empty ``POST``
|
||||
|
@ -563,19 +564,19 @@ streaming response if (and only if) no middleware accesses the
|
|||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
This technique is fragile and was deprecated in Django 1.5. If you need the
|
||||
response to be streamed from the iterator to the client, you should use the
|
||||
:class:`StreamingHttpResponse` class instead.
|
||||
This technique is fragile and was deprecated in Django 1.5. If you need the
|
||||
response to be streamed from the iterator to the client, you should use the
|
||||
:class:`StreamingHttpResponse` class instead.
|
||||
|
||||
As of Django 1.7, when :class:`HttpResponse` is instantiated with an
|
||||
iterator, it will consume it immediately, store the response content as a
|
||||
string, and discard the iterator.
|
||||
As of Django 1.7, when :class:`HttpResponse` is instantiated with an
|
||||
iterator, it will consume it immediately, store the response content as a
|
||||
string, and discard the iterator.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
You can now use :class:`HttpResponse` as a file-like object even if it was
|
||||
instantiated with an iterator. Django will consume and save the content of
|
||||
the iterator on first access.
|
||||
You can now use :class:`HttpResponse` as a file-like object even if it was
|
||||
instantiated with an iterator. Django will consume and save the content of
|
||||
the iterator on first access.
|
||||
|
||||
Setting headers
|
||||
~~~~~~~~~~~~~~~
|
||||
|
|
|
@ -1486,6 +1486,7 @@ randomly-generated ``SECRET_KEY`` to each new project.
|
|||
execution vulnerabilities.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Django will now refuse to start if :setting:`SECRET_KEY` is not set.
|
||||
|
||||
.. setting:: SECURE_PROXY_SSL_HEADER
|
||||
|
@ -1771,7 +1772,7 @@ See also :setting:`DATE_INPUT_FORMATS` and :setting:`DATETIME_INPUT_FORMATS`.
|
|||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Input format with microseconds has been added.
|
||||
Input format with microseconds has been added.
|
||||
|
||||
.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior
|
||||
|
||||
|
@ -2055,11 +2056,11 @@ decorator, for example.
|
|||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
This setting now also accepts view function names and
|
||||
:ref:`named URL patterns <naming-url-patterns>` which can be used to reduce
|
||||
configuration duplication since you no longer have to define the URL in two
|
||||
places (``settings`` and URLconf).
|
||||
For backward compatibility reasons the default remains unchanged.
|
||||
This setting now also accepts view function names and
|
||||
:ref:`named URL patterns <naming-url-patterns>` which can be used to reduce
|
||||
configuration duplication since you no longer have to define the URL in two
|
||||
places (``settings`` and URLconf).
|
||||
For backward compatibility reasons the default remains unchanged.
|
||||
|
||||
.. setting:: LOGIN_URL
|
||||
|
||||
|
@ -2073,11 +2074,11 @@ The URL where requests are redirected for login, especially when using the
|
|||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
This setting now also accepts view function names and
|
||||
:ref:`named URL patterns <naming-url-patterns>` which can be used to reduce
|
||||
configuration duplication since you no longer have to define the URL in two
|
||||
places (``settings`` and URLconf).
|
||||
For backward compatibility reasons the default remains unchanged.
|
||||
This setting now also accepts view function names and
|
||||
:ref:`named URL patterns <naming-url-patterns>` which can be used to reduce
|
||||
configuration duplication since you no longer have to define the URL in two
|
||||
places (``settings`` and URLconf).
|
||||
For backward compatibility reasons the default remains unchanged.
|
||||
|
||||
.. setting:: LOGOUT_URL
|
||||
|
||||
|
|
|
@ -78,13 +78,13 @@ Methods
|
|||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Historically, this parameter was only called ``mimetype`` (now
|
||||
deprecated), but since this is actually the value included in the HTTP
|
||||
``Content-Type`` header, it can also include the character set
|
||||
encoding, which makes it more than just a MIME type specification. If
|
||||
``mimetype`` is specified (not ``None``), that value is used.
|
||||
Otherwise, ``content_type`` is used. If neither is given,
|
||||
:setting:`DEFAULT_CONTENT_TYPE` is used.
|
||||
Historically, this parameter was only called ``mimetype`` (now
|
||||
deprecated), but since this is actually the value included in the HTTP
|
||||
``Content-Type`` header, it can also include the character set
|
||||
encoding, which makes it more than just a MIME type specification. If
|
||||
``mimetype`` is specified (not ``None``), that value is used.
|
||||
Otherwise, ``content_type`` is used. If neither is given,
|
||||
:setting:`DEFAULT_CONTENT_TYPE` is used.
|
||||
|
||||
|
||||
.. method:: SimpleTemplateResponse.resolve_context(context)
|
||||
|
|
|
@ -272,6 +272,7 @@ Every context contains ``True``, ``False`` and ``None``. As you would expect,
|
|||
these variables resolve to the corresponding Python objects.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
Before Django 1.5, these variables weren't a special case, and they
|
||||
resolved to ``None`` unless you defined them in the context.
|
||||
|
||||
|
|
|
@ -191,19 +191,19 @@ call to ``{% cycle %}`` doesn't specify silent::
|
|||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
To improve safety, future versions of ``cycle`` will automatically escape
|
||||
their output. You're encouraged to activate this behavior by loading
|
||||
``cycle`` from the ``future`` template library::
|
||||
To improve safety, future versions of ``cycle`` will automatically escape
|
||||
their output. You're encouraged to activate this behavior by loading
|
||||
``cycle`` from the ``future`` template library::
|
||||
|
||||
{% load cycle from future %}
|
||||
{% load cycle from future %}
|
||||
|
||||
When using the ``future`` version, you can disable auto-escaping with::
|
||||
When using the ``future`` version, you can disable auto-escaping with::
|
||||
|
||||
{% for o in some_list %}
|
||||
<tr class="{% autoescape off %}{% cycle rowvalue1 rowvalue2 %}{% endautoescape %}">
|
||||
...
|
||||
</tr>
|
||||
{% endfor %}
|
||||
{% for o in some_list %}
|
||||
<tr class="{% autoescape off %}{% cycle rowvalue1 rowvalue2 %}{% endautoescape %}">
|
||||
...
|
||||
</tr>
|
||||
{% endfor %}
|
||||
|
||||
.. templatetag:: debug
|
||||
|
||||
|
@ -294,21 +294,21 @@ to escape the variables in the firstof tag, you must do so explicitly::
|
|||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
To improve safety, future versions of ``firstof`` will automatically escape
|
||||
their output. You're encouraged to activate this behavior by loading
|
||||
``firstof`` from the ``future`` template library::
|
||||
To improve safety, future versions of ``firstof`` will automatically escape
|
||||
their output. You're encouraged to activate this behavior by loading
|
||||
``firstof`` from the ``future`` template library::
|
||||
|
||||
{% load firstof from future %}
|
||||
{% load firstof from future %}
|
||||
|
||||
When using the ``future`` version, you can disable auto-escaping with::
|
||||
When using the ``future`` version, you can disable auto-escaping with::
|
||||
|
||||
{% autoescape off %}
|
||||
{% firstof var1 var2 var3 "<strong>fallback value</strong>" %}
|
||||
{% endautoescape %}
|
||||
{% autoescape off %}
|
||||
{% firstof var1 var2 var3 "<strong>fallback value</strong>" %}
|
||||
{% endautoescape %}
|
||||
|
||||
Or if only some variables should be escaped, you can use::
|
||||
Or if only some variables should be escaped, you can use::
|
||||
|
||||
{% firstof var1 var2|safe var3 "<strong>fallback value</strong>"|safe %}
|
||||
{% firstof var1 var2|safe var3 "<strong>fallback value</strong>"|safe %}
|
||||
|
||||
.. templatetag:: for
|
||||
|
||||
|
@ -1065,6 +1065,7 @@ by the context as to the current application.
|
|||
Don't forget to put quotes around the function path or pattern name!
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
The first parameter used not to be quoted, which was inconsistent with
|
||||
other template tags. Since Django 1.5, it is evaluated according to
|
||||
the usual rules: it can be a quoted string or a variable that will be
|
||||
|
|
|
@ -47,26 +47,26 @@ You can use Unicode strings, or you can use normal strings (sometimes called
|
|||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
In Python 3, the logic is reversed, that is normal strings are Unicode, and
|
||||
when you want to specifically create a bytestring, you have to prefix the
|
||||
string with a 'b'. As we are doing in Django code from version 1.5,
|
||||
we recommend that you import ``unicode_literals`` from the __future__ library
|
||||
in your code. Then, when you specifically want to create a bytestring literal,
|
||||
prefix the string with 'b'.
|
||||
In Python 3, the logic is reversed, that is normal strings are Unicode, and
|
||||
when you want to specifically create a bytestring, you have to prefix the
|
||||
string with a 'b'. As we are doing in Django code from version 1.5,
|
||||
we recommend that you import ``unicode_literals`` from the __future__ library
|
||||
in your code. Then, when you specifically want to create a bytestring literal,
|
||||
prefix the string with 'b'.
|
||||
|
||||
Python 2 legacy::
|
||||
Python 2 legacy::
|
||||
|
||||
my_string = "This is a bytestring"
|
||||
my_unicode = u"This is an Unicode string"
|
||||
my_string = "This is a bytestring"
|
||||
my_unicode = u"This is an Unicode string"
|
||||
|
||||
Python 2 with unicode literals or Python 3::
|
||||
Python 2 with unicode literals or Python 3::
|
||||
|
||||
from __future__ import unicode_literals
|
||||
from __future__ import unicode_literals
|
||||
|
||||
my_string = b"This is a bytestring"
|
||||
my_unicode = "This is an Unicode string"
|
||||
my_string = b"This is a bytestring"
|
||||
my_unicode = "This is an Unicode string"
|
||||
|
||||
See also :doc:`Python 3 compatibility </topics/python3>`.
|
||||
See also :doc:`Python 3 compatibility </topics/python3>`.
|
||||
|
||||
.. warning::
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue