mirror of
https://github.com/django/django.git
synced 2025-10-31 09:41:08 +00:00
Merge branch 'django:main' into ticket_34034
This commit is contained in:
Mariana
GitHub
Binary file not shown.
|
Before Width: | Height: | Size: 55 KiB After Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 37 KiB After Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 47 KiB After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.0 KiB After Width: | Height: | Size: 997 B |
@@ -41,7 +41,8 @@ If you're not using the default project template, here are the requirements:
|
||||
<TEMPLATES-OPTIONS>`.
|
||||
|
||||
#. If you've customized the :setting:`MIDDLEWARE` setting,
|
||||
:class:`django.contrib.auth.middleware.AuthenticationMiddleware` and
|
||||
:class:`django.contrib.sessions.middleware.SessionMiddleware`,
|
||||
:class:`django.contrib.auth.middleware.AuthenticationMiddleware`, and
|
||||
:class:`django.contrib.messages.middleware.MessageMiddleware` must be
|
||||
included.
|
||||
|
||||
|
||||
@@ -197,13 +197,23 @@ Methods
|
||||
been called for this user.
|
||||
|
||||
.. method:: get_user_permissions(obj=None)
|
||||
.. method:: aget_user_permissions(obj=None)
|
||||
|
||||
*Asynchronous version*: ``aget_user_permissions()``
|
||||
|
||||
Returns a set of permission strings that the user has directly.
|
||||
|
||||
If ``obj`` is passed in, only returns the user permissions for this
|
||||
specific object.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``aget_user_permissions()`` method was added.
|
||||
|
||||
.. method:: get_group_permissions(obj=None)
|
||||
.. method:: aget_group_permissions(obj=None)
|
||||
|
||||
*Asynchronous version*: ``aget_group_permissions()``
|
||||
|
||||
Returns a set of permission strings that the user has, through their
|
||||
groups.
|
||||
@@ -211,7 +221,14 @@ Methods
|
||||
If ``obj`` is passed in, only returns the group permissions for
|
||||
this specific object.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``aget_group_permissions()`` method was added.
|
||||
|
||||
.. method:: get_all_permissions(obj=None)
|
||||
.. method:: aget_all_permissions(obj=None)
|
||||
|
||||
*Asynchronous version*: ``aget_all_permissions()``
|
||||
|
||||
Returns a set of permission strings that the user has, both through
|
||||
group and user permissions.
|
||||
@@ -219,7 +236,14 @@ Methods
|
||||
If ``obj`` is passed in, only returns the permissions for this
|
||||
specific object.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``aget_all_permissions()`` method was added.
|
||||
|
||||
.. method:: has_perm(perm, obj=None)
|
||||
.. method:: ahas_perm(perm, obj=None)
|
||||
|
||||
*Asynchronous version*: ``ahas_perm()``
|
||||
|
||||
Returns ``True`` if the user has the specified permission, where perm
|
||||
is in the format ``"<app label>.<permission codename>"``. (see
|
||||
@@ -230,7 +254,14 @@ Methods
|
||||
If ``obj`` is passed in, this method won't check for a permission for
|
||||
the model, but for this specific object.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``ahas_perm()`` method was added.
|
||||
|
||||
.. method:: has_perms(perm_list, obj=None)
|
||||
.. method:: ahas_perms(perm_list, obj=None)
|
||||
|
||||
*Asynchronous version*: ``ahas_perms()``
|
||||
|
||||
Returns ``True`` if the user has each of the specified permissions,
|
||||
where each perm is in the format
|
||||
@@ -241,13 +272,24 @@ Methods
|
||||
If ``obj`` is passed in, this method won't check for permissions for
|
||||
the model, but for the specific object.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``ahas_perms()`` method was added.
|
||||
|
||||
.. method:: has_module_perms(package_name)
|
||||
.. method:: ahas_module_perms(package_name)
|
||||
|
||||
*Asynchronous version*: ``ahas_module_perms()``
|
||||
|
||||
Returns ``True`` if the user has any permissions in the given package
|
||||
(the Django app label). If the user is inactive, this method will
|
||||
always return ``False``. For an active superuser, this method will
|
||||
always return ``True``.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``ahas_module_perms()`` method was added.
|
||||
|
||||
.. method:: email_user(subject, message, from_email=None, **kwargs)
|
||||
|
||||
Sends an email to the user. If ``from_email`` is ``None``, Django uses
|
||||
@@ -264,6 +306,9 @@ Manager methods
|
||||
by :class:`~django.contrib.auth.models.BaseUserManager`):
|
||||
|
||||
.. method:: create_user(username, email=None, password=None, **extra_fields)
|
||||
.. method:: acreate_user(username, email=None, password=None, **extra_fields)
|
||||
|
||||
*Asynchronous version*: ``acreate_user()``
|
||||
|
||||
Creates, saves and returns a :class:`~django.contrib.auth.models.User`.
|
||||
|
||||
@@ -285,11 +330,22 @@ Manager methods
|
||||
|
||||
See :ref:`Creating users <topics-auth-creating-users>` for example usage.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``acreate_user()`` method was added.
|
||||
|
||||
.. method:: create_superuser(username, email=None, password=None, **extra_fields)
|
||||
.. method:: acreate_superuser(username, email=None, password=None, **extra_fields)
|
||||
|
||||
*Asynchronous version*: ``acreate_superuser()``
|
||||
|
||||
Same as :meth:`create_user`, but sets :attr:`~models.User.is_staff` and
|
||||
:attr:`~models.User.is_superuser` to ``True``.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``acreate_superuser()`` method was added.
|
||||
|
||||
.. method:: with_perm(perm, is_active=True, include_superusers=True, backend=None, obj=None)
|
||||
|
||||
Returns users that have the given permission ``perm`` either in the
|
||||
@@ -499,23 +555,51 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
|
||||
methods. By default, it will reject any user and provide no permissions.
|
||||
|
||||
.. method:: get_user_permissions(user_obj, obj=None)
|
||||
.. method:: aget_user_permissions(user_obj, obj=None)
|
||||
|
||||
*Asynchronous version*: ``aget_user_permissions()``
|
||||
|
||||
Returns an empty set.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``aget_user_permissions()`` function was added.
|
||||
|
||||
.. method:: get_group_permissions(user_obj, obj=None)
|
||||
.. method:: aget_group_permissions(user_obj, obj=None)
|
||||
|
||||
*Asynchronous version*: ``aget_group_permissions()``
|
||||
|
||||
Returns an empty set.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``aget_group_permissions()`` function was added.
|
||||
|
||||
.. method:: get_all_permissions(user_obj, obj=None)
|
||||
.. method:: aget_all_permissions(user_obj, obj=None)
|
||||
|
||||
*Asynchronous version*: ``aget_all_permissions()``
|
||||
|
||||
Uses :meth:`get_user_permissions` and :meth:`get_group_permissions` to
|
||||
get the set of permission strings the ``user_obj`` has.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``aget_all_permissions()`` function was added.
|
||||
|
||||
.. method:: has_perm(user_obj, perm, obj=None)
|
||||
.. method:: ahas_perm(user_obj, perm, obj=None)
|
||||
|
||||
*Asynchronous version*: ``ahas_perm()``
|
||||
|
||||
Uses :meth:`get_all_permissions` to check if ``user_obj`` has the
|
||||
permission string ``perm``.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``ahas_perm()`` function was added.
|
||||
|
||||
.. class:: ModelBackend
|
||||
|
||||
This is the default authentication backend used by Django. It
|
||||
@@ -539,6 +623,9 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
|
||||
unlike others methods it returns an empty queryset if ``obj is not None``.
|
||||
|
||||
.. method:: authenticate(request, username=None, password=None, **kwargs)
|
||||
.. method:: aauthenticate(request, username=None, password=None, **kwargs)
|
||||
|
||||
*Asynchronous version*: ``aauthenticate()``
|
||||
|
||||
Tries to authenticate ``username`` with ``password`` by calling
|
||||
:meth:`User.check_password
|
||||
@@ -552,38 +639,77 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
|
||||
if it wasn't provided to :func:`~django.contrib.auth.authenticate`
|
||||
(which passes it on to the backend).
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``aauthenticate()`` function was added.
|
||||
|
||||
.. method:: get_user_permissions(user_obj, obj=None)
|
||||
.. method:: aget_user_permissions(user_obj, obj=None)
|
||||
|
||||
*Asynchronous version*: ``aget_user_permissions()``
|
||||
|
||||
Returns the set of permission strings the ``user_obj`` has from their
|
||||
own user permissions. Returns an empty set if
|
||||
:attr:`~django.contrib.auth.models.AbstractBaseUser.is_anonymous` or
|
||||
:attr:`~django.contrib.auth.models.CustomUser.is_active` is ``False``.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``aget_user_permissions()`` function was added.
|
||||
|
||||
.. method:: get_group_permissions(user_obj, obj=None)
|
||||
.. method:: aget_group_permissions(user_obj, obj=None)
|
||||
|
||||
*Asynchronous version*: ``aget_group_permissions()``
|
||||
|
||||
Returns the set of permission strings the ``user_obj`` has from the
|
||||
permissions of the groups they belong. Returns an empty set if
|
||||
:attr:`~django.contrib.auth.models.AbstractBaseUser.is_anonymous` or
|
||||
:attr:`~django.contrib.auth.models.CustomUser.is_active` is ``False``.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``aget_group_permissions()`` function was added.
|
||||
|
||||
.. method:: get_all_permissions(user_obj, obj=None)
|
||||
.. method:: aget_all_permissions(user_obj, obj=None)
|
||||
|
||||
*Asynchronous version*: ``aget_all_permissions()``
|
||||
|
||||
Returns the set of permission strings the ``user_obj`` has, including both
|
||||
user permissions and group permissions. Returns an empty set if
|
||||
:attr:`~django.contrib.auth.models.AbstractBaseUser.is_anonymous` or
|
||||
:attr:`~django.contrib.auth.models.CustomUser.is_active` is ``False``.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``aget_all_permissions()`` function was added.
|
||||
|
||||
.. method:: has_perm(user_obj, perm, obj=None)
|
||||
.. method:: ahas_perm(user_obj, perm, obj=None)
|
||||
|
||||
*Asynchronous version*: ``ahas_perm()``
|
||||
|
||||
Uses :meth:`get_all_permissions` to check if ``user_obj`` has the
|
||||
permission string ``perm``. Returns ``False`` if the user is not
|
||||
:attr:`~django.contrib.auth.models.CustomUser.is_active`.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``ahas_perm()`` function was added.
|
||||
|
||||
.. method:: has_module_perms(user_obj, app_label)
|
||||
.. method:: ahas_module_perms(user_obj, app_label)
|
||||
|
||||
*Asynchronous version*: ``ahas_module_perms()``
|
||||
|
||||
Returns whether the ``user_obj`` has any permissions on the app
|
||||
``app_label``.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``ahas_module_perms()`` function was added.
|
||||
|
||||
.. method:: user_can_authenticate()
|
||||
|
||||
Returns whether the user is allowed to authenticate. To match the
|
||||
@@ -637,6 +763,9 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
|
||||
created if not already in the database Defaults to ``True``.
|
||||
|
||||
.. method:: authenticate(request, remote_user)
|
||||
.. method:: aauthenticate(request, remote_user)
|
||||
|
||||
*Asynchronous version*: ``aauthenticate()``
|
||||
|
||||
The username passed as ``remote_user`` is considered trusted. This
|
||||
method returns the user object with the given username, creating a new
|
||||
@@ -651,6 +780,10 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
|
||||
if it wasn't provided to :func:`~django.contrib.auth.authenticate`
|
||||
(which passes it on to the backend).
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``aauthenticate()`` function was added.
|
||||
|
||||
.. method:: clean_username(username)
|
||||
|
||||
Performs any cleaning on the ``username`` (e.g. stripping LDAP DN
|
||||
@@ -658,12 +791,17 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
|
||||
the cleaned username.
|
||||
|
||||
.. method:: configure_user(request, user, created=True)
|
||||
.. method:: aconfigure_user(request, user, created=True)
|
||||
|
||||
*Asynchronous version*: ``aconfigure_user()``
|
||||
|
||||
Configures the user on each authentication attempt. This method is
|
||||
called immediately after fetching or creating the user being
|
||||
authenticated, and can be used to perform custom setup actions, such as
|
||||
setting the user's groups based on attributes in an LDAP directory.
|
||||
Returns the user object.
|
||||
Returns the user object. When fetching or creating an user is called
|
||||
from a synchronous context, ``configure_user`` is called,
|
||||
``aconfigure_user`` is called from async contexts.
|
||||
|
||||
The setup can be performed either once when the user is created
|
||||
(``created`` is ``True``) or on existing users (``created`` is
|
||||
@@ -674,6 +812,10 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
|
||||
if it wasn't provided to :func:`~django.contrib.auth.authenticate`
|
||||
(which passes it on to the backend).
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
``aconfigure_user()`` function was added.
|
||||
|
||||
.. method:: user_can_authenticate()
|
||||
|
||||
Returns whether the user is allowed to authenticate. This method
|
||||
|
||||
@@ -5,8 +5,8 @@ Geolocation with GeoIP2
|
||||
.. module:: django.contrib.gis.geoip2
|
||||
:synopsis: Python interface for MaxMind's GeoIP2 databases.
|
||||
|
||||
The :class:`GeoIP2` object is a wrapper for the `MaxMind geoip2 Python
|
||||
library`__. [#]_
|
||||
The :class:`GeoIP2` object is a wrapper for the :pypi:`MaxMind geoip2 Python
|
||||
library <geoip2>`. [#]_
|
||||
|
||||
In order to perform IP-based geolocation, the :class:`GeoIP2` object requires
|
||||
the :pypi:`geoip2` Python package and the GeoIP ``Country`` and/or ``City``
|
||||
@@ -18,7 +18,6 @@ the :setting:`GEOIP_PATH` setting.
|
||||
Additionally, it is recommended to install the `libmaxminddb C library`__, so
|
||||
that ``geoip2`` can leverage the C library's faster speed.
|
||||
|
||||
__ https://geoip2.readthedocs.io/
|
||||
__ https://dev.maxmind.com/geoip/geolite2-free-geolocation-data
|
||||
__ https://db-ip.com/db/lite.php
|
||||
__ https://github.com/maxmind/libmaxminddb/
|
||||
@@ -196,8 +195,9 @@ Exceptions
|
||||
|
||||
.. exception:: GeoIP2Exception
|
||||
|
||||
The exception raised when an error occurs in a call to the underlying
|
||||
``geoip2`` library.
|
||||
The exception raised when an error occurs in the :class:`GeoIP2` wrapper.
|
||||
Exceptions from the underlying ``geoip2`` library are passed through
|
||||
unchanged.
|
||||
|
||||
.. rubric:: Footnotes
|
||||
.. [#] GeoIP(R) is a registered trademark of MaxMind, Inc.
|
||||
|
||||
@@ -5,16 +5,16 @@ Installing Geospatial libraries
|
||||
GeoDjango uses and/or provides interfaces for the following open source
|
||||
geospatial libraries:
|
||||
|
||||
======================== ==================================== ================================ ===========================================
|
||||
======================== ==================================== ================================ ======================================
|
||||
Program Description Required Supported Versions
|
||||
======================== ==================================== ================================ ===========================================
|
||||
======================== ==================================== ================================ ======================================
|
||||
:doc:`GEOS <../geos>` Geometry Engine Open Source Yes 3.12, 3.11, 3.10, 3.9, 3.8
|
||||
`PROJ`_ Cartographic Projections library Yes (PostgreSQL and SQLite only) 9.x, 8.x, 7.x, 6.x
|
||||
:doc:`GDAL <../gdal>` Geospatial Data Abstraction Library Yes 3.8, 3.7, 3.6, 3.5, 3.4, 3.3, 3.2, 3.1, 3.0
|
||||
:doc:`GDAL <../gdal>` Geospatial Data Abstraction Library Yes 3.8, 3.7, 3.6, 3.5, 3.4, 3.3, 3.2, 3.1
|
||||
:doc:`GeoIP <../geoip2>` IP-based geolocation library No 2
|
||||
`PostGIS`__ Spatial extensions for PostgreSQL Yes (PostgreSQL only) 3.4, 3.3, 3.2, 3.1
|
||||
`SpatiaLite`__ Spatial extensions for SQLite Yes (SQLite only) 5.1, 5.0, 4.3
|
||||
======================== ==================================== ================================ ===========================================
|
||||
======================== ==================================== ================================ ======================================
|
||||
|
||||
Note that older or more recent versions of these libraries *may* also work
|
||||
totally fine with GeoDjango. Your mileage may vary.
|
||||
@@ -26,7 +26,6 @@ totally fine with GeoDjango. Your mileage may vary.
|
||||
GEOS 3.10.0 2021-10-20
|
||||
GEOS 3.11.0 2022-07-01
|
||||
GEOS 3.12.0 2023-06-27
|
||||
GDAL 3.0.0 2019-05
|
||||
GDAL 3.1.0 2020-05-07
|
||||
GDAL 3.2.0 2020-11-02
|
||||
GDAL 3.3.0 2021-05-03
|
||||
|
||||
@@ -479,8 +479,6 @@ MySQL has a couple drivers that implement the Python Database API described in
|
||||
|
||||
.. _MySQL Connector/Python: https://dev.mysql.com/downloads/connector/python/
|
||||
|
||||
These drivers are thread-safe and provide connection pooling.
|
||||
|
||||
In addition to a DB API driver, Django needs an adapter to access the database
|
||||
drivers from its ORM. Django provides an adapter for mysqlclient while MySQL
|
||||
Connector/Python includes `its own`_.
|
||||
|
||||
@@ -870,11 +870,11 @@ are reserved for the superuser (root).
|
||||
This server uses the WSGI application object specified by the
|
||||
:setting:`WSGI_APPLICATION` setting.
|
||||
|
||||
DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
|
||||
security audits or performance tests. (And that's how it's gonna stay. We're in
|
||||
the business of making web frameworks, not web servers, so improving this
|
||||
server to be able to handle a production environment is outside the scope of
|
||||
Django.)
|
||||
.. warning:: DO NOT USE THIS SERVER IN A PRODUCTION SETTING.
|
||||
|
||||
This lightweight development server has not gone through security audits or
|
||||
performance tests, hence is unsuitable for production. Making this server
|
||||
able to handle a production environment is outside the scope of Django.
|
||||
|
||||
The development server automatically reloads Python code for each request, as
|
||||
needed. You don't need to restart the server for code changes to take effect.
|
||||
@@ -947,6 +947,20 @@ multithreaded by default.
|
||||
Uses IPv6 for the development server. This changes the default IP address from
|
||||
``127.0.0.1`` to ``::1``.
|
||||
|
||||
.. envvar:: HIDE_PRODUCTION_WARNING
|
||||
|
||||
.. versionadded:: 5.2
|
||||
|
||||
By default, a warning is printed to the console that ``runserver`` is not
|
||||
suitable for production:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead.
|
||||
For more information on production servers see: https://docs.djangoproject.com/en/|version|/howto/deployment/
|
||||
|
||||
Set this environment variable to ``"true"`` to hide this warning.
|
||||
|
||||
Examples of using different ports and addresses
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -1078,7 +1092,7 @@ Python interpreter, use ``python`` as the interface name, like so:
|
||||
.. _IPython: https://ipython.org/
|
||||
.. _bpython: https://bpython-interpreter.org/
|
||||
|
||||
.. django-admin-option:: --nostartup
|
||||
.. django-admin-option:: --no-startup
|
||||
|
||||
Disables reading the startup script for the "plain" Python interpreter. By
|
||||
default, the script pointed to by the :envvar:`PYTHONSTARTUP` environment
|
||||
|
||||
@@ -129,8 +129,7 @@ The ``Storage`` class
|
||||
.. method:: exists(name)
|
||||
|
||||
Returns ``True`` if a file referenced by the given name already exists
|
||||
in the storage system, or ``False`` if the name is available for a new
|
||||
file.
|
||||
in the storage system.
|
||||
|
||||
.. method:: get_accessed_time(name)
|
||||
|
||||
|
||||
@@ -801,11 +801,11 @@ For each field, we describe the default widget used if you don't specify
|
||||
* Error message keys: ``required``, ``invalid``, ``missing``, ``empty``,
|
||||
``invalid_image``
|
||||
|
||||
Using an ``ImageField`` requires that `Pillow`_ is installed with support
|
||||
for the image formats you use. If you encounter a ``corrupt image`` error
|
||||
when you upload an image, it usually means that Pillow doesn't understand
|
||||
its format. To fix this, install the appropriate library and reinstall
|
||||
Pillow.
|
||||
Using an ``ImageField`` requires that :pypi:`pillow` is installed with
|
||||
support for the image formats you use. If you encounter a ``corrupt image``
|
||||
error when you upload an image, it usually means that Pillow doesn't
|
||||
understand its format. To fix this, install the appropriate library and
|
||||
reinstall Pillow.
|
||||
|
||||
When you use an ``ImageField`` on a form, you must also remember to
|
||||
:ref:`bind the file data to the form <binding-uploaded-files>`.
|
||||
@@ -851,7 +851,6 @@ For each field, we describe the default widget used if you don't specify
|
||||
image's content type if Pillow can determine it, otherwise it will be set
|
||||
to ``None``.
|
||||
|
||||
.. _Pillow: https://pillow.readthedocs.io/en/latest/
|
||||
.. _Image: https://pillow.readthedocs.io/en/latest/reference/Image.html
|
||||
|
||||
``IntegerField``
|
||||
|
||||
@@ -570,6 +570,48 @@ These widgets make use of the HTML elements ``input`` and ``textarea``.
|
||||
* ``template_name``: ``'django/forms/widgets/url.html'``
|
||||
* Renders as: ``<input type="url" ...>``
|
||||
|
||||
``ColorInput``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 5.2
|
||||
|
||||
.. class:: ColorInput
|
||||
|
||||
* ``input_type``: ``'color'``
|
||||
* ``template_name``:``'django/forms/widgets/color.html'``
|
||||
* Renders as: ``<input type="color" ...>``
|
||||
|
||||
``SearchInput``
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 5.2
|
||||
|
||||
.. class:: SearchInput
|
||||
|
||||
* ``input_type``: ``'search'``
|
||||
* ``template_name``: ``'django/forms/widgets/search.html'``
|
||||
* Renders as: ``<input type="search" ...>``
|
||||
|
||||
``TelInput``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 5.2
|
||||
|
||||
.. class:: TelInput
|
||||
|
||||
* ``input_type``: ``'tel'``
|
||||
* ``template_name``: ``'django/forms/widgets/tel.html'``
|
||||
* Renders as: ``<input type="tel" ...>``
|
||||
|
||||
Browsers perform no client-side validation by default because telephone
|
||||
number formats vary so much around the world. You can add some by setting
|
||||
``pattern``, ``minlength``, or ``maxlength`` in the :attr:`Widget.attrs`
|
||||
argument.
|
||||
|
||||
Additionally, you can add server-side validation to your form field with a
|
||||
validator like :class:`~django.core.validators.RegexValidator` or via
|
||||
third-party packages, such as :pypi:`django-phonenumber-field`.
|
||||
|
||||
``PasswordInput``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
@@ -209,6 +209,18 @@ Django development server. This logger generates an ``INFO`` message upon
|
||||
detecting a modification in a source code file and may produce ``WARNING``
|
||||
messages during filesystem inspection and event subscription processes.
|
||||
|
||||
.. _django-contrib-auth-logger:
|
||||
|
||||
``django.contrib.auth``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 4.2.16
|
||||
|
||||
Log messages related to :doc:`contrib/auth`, particularly ``ERROR`` messages
|
||||
are generated when a :class:`~django.contrib.auth.forms.PasswordResetForm` is
|
||||
successfully submitted but the password reset email cannot be delivered due to
|
||||
a mail sending exception.
|
||||
|
||||
.. _django-contrib-gis-logger:
|
||||
|
||||
``django.contrib.gis``
|
||||
|
||||
@@ -34,6 +34,12 @@ defines. See the :doc:`cache documentation </topics/cache>`.
|
||||
|
||||
.. class:: CommonMiddleware
|
||||
|
||||
.. attribute:: response_redirect_class
|
||||
|
||||
Defaults to :class:`~django.http.HttpResponsePermanentRedirect`. Subclass
|
||||
``CommonMiddleware`` and override the attribute to customize the redirects
|
||||
issued by the middleware.
|
||||
|
||||
Adds a few conveniences for perfectionists:
|
||||
|
||||
* Forbids access to user agents in the :setting:`DISALLOWED_USER_AGENTS`
|
||||
@@ -75,12 +81,6 @@ Adds a few conveniences for perfectionists:
|
||||
|
||||
* Sets the ``Content-Length`` header for non-streaming responses.
|
||||
|
||||
.. attribute:: CommonMiddleware.response_redirect_class
|
||||
|
||||
Defaults to :class:`~django.http.HttpResponsePermanentRedirect`. Subclass
|
||||
``CommonMiddleware`` and override the attribute to customize the redirects
|
||||
issued by the middleware.
|
||||
|
||||
.. class:: BrokenLinkEmailsMiddleware
|
||||
|
||||
* Sends broken link notification emails to :setting:`MANAGERS` (see
|
||||
@@ -164,16 +164,16 @@ Locale middleware
|
||||
|
||||
.. class:: LocaleMiddleware
|
||||
|
||||
.. attribute:: LocaleMiddleware.response_redirect_class
|
||||
|
||||
Defaults to :class:`~django.http.HttpResponseRedirect`. Subclass
|
||||
``LocaleMiddleware`` and override the attribute to customize the
|
||||
redirects issued by the middleware.
|
||||
|
||||
Enables language selection based on data from the request. It customizes
|
||||
content for each user. See the :doc:`internationalization documentation
|
||||
</topics/i18n/translation>`.
|
||||
|
||||
.. attribute:: LocaleMiddleware.response_redirect_class
|
||||
|
||||
Defaults to :class:`~django.http.HttpResponseRedirect`. Subclass
|
||||
``LocaleMiddleware`` and override the attribute to customize the redirects
|
||||
issued by the middleware.
|
||||
|
||||
Message middleware
|
||||
------------------
|
||||
|
||||
@@ -500,56 +500,81 @@ every incoming ``HttpRequest`` object. See :ref:`Authentication in web requests
|
||||
|
||||
.. class:: LoginRequiredMiddleware
|
||||
|
||||
Subclass the middleware and override the following attributes and methods
|
||||
to customize behavior for unauthenticated requests.
|
||||
|
||||
.. attribute:: redirect_field_name
|
||||
|
||||
Defaults to ``"next"``.
|
||||
|
||||
.. method:: get_login_url()
|
||||
|
||||
Returns the URL that unauthenticated requests will be redirected to. This
|
||||
result is either the ``login_url`` set on the
|
||||
:func:`~django.contrib.auth.decorators.login_required` decorator (if not
|
||||
``None``), or :setting:`settings.LOGIN_URL <LOGIN_URL>`.
|
||||
|
||||
.. method:: get_redirect_field_name()
|
||||
|
||||
Returns the name of the query parameter that contains the URL the user
|
||||
should be redirected to after a successful login. This result is either
|
||||
the ``redirect_field_name`` set on the
|
||||
:func:`~.django.contrib.auth.decorators.login_required` decorator (if not
|
||||
``None``), or :attr:`redirect_field_name`. If ``None`` is returned, a query
|
||||
parameter won't be added.
|
||||
|
||||
.. versionadded:: 5.1
|
||||
|
||||
Redirects all unauthenticated requests to a login page. For admin views, this
|
||||
redirects to the admin login. For all other views, this will redirect to
|
||||
:setting:`settings.LOGIN_URL <LOGIN_URL>`. This can be customized by using the
|
||||
:func:`~.django.contrib.auth.decorators.login_required` decorator and setting
|
||||
``login_url`` or ``redirect_field_name`` for the view. For example::
|
||||
Redirects all unauthenticated requests to a login page, except for views
|
||||
excluded with :func:`~.django.contrib.auth.decorators.login_not_required`. The
|
||||
login page defaults to :setting:`settings.LOGIN_URL <LOGIN_URL>`, but can be
|
||||
customized.
|
||||
|
||||
Enable this middleware by adding it to the :setting:`MIDDLEWARE` setting
|
||||
**after** :class:`~django.contrib.auth.middleware.AuthenticationMiddleware`::
|
||||
|
||||
MIDDLEWARE = [
|
||||
"...",
|
||||
"django.contrib.auth.middleware.AuthenticationMiddleware",
|
||||
"django.contrib.auth.middleware.LoginRequiredMiddleware",
|
||||
"...",
|
||||
]
|
||||
|
||||
Make a view public, allowing unauthenticated requests, with
|
||||
:func:`~.django.contrib.auth.decorators.login_not_required`. For example::
|
||||
|
||||
from django.contrib.auth.decorators import login_not_required
|
||||
|
||||
|
||||
@login_not_required
|
||||
def contact_us(request): ...
|
||||
|
||||
Customize the login URL or field name for authenticated views with the
|
||||
:func:`~.django.contrib.auth.decorators.login_required` decorator to set
|
||||
``login_url`` or ``redirect_field_name`` respectively. For example::
|
||||
|
||||
from django.contrib.auth.decorators import login_required
|
||||
from django.utils.decorators import method_decorator
|
||||
from django.views.generic import View
|
||||
|
||||
|
||||
@login_required(login_url="/books/login/", redirect_field_name="redirect_to")
|
||||
def book_dashboard(request): ...
|
||||
|
||||
|
||||
@method_decorator(
|
||||
login_required(login_url="/login/", redirect_field_name="redirect_to"),
|
||||
login_required(login_url="/books/login/", redirect_field_name="redirect_to"),
|
||||
name="dispatch",
|
||||
)
|
||||
class MyView(View):
|
||||
class BookMetrics(View):
|
||||
pass
|
||||
|
||||
|
||||
@login_required(login_url="/login/", redirect_field_name="redirect_to")
|
||||
def my_view(request): ...
|
||||
|
||||
Views using the :func:`~django.contrib.auth.decorators.login_not_required`
|
||||
decorator are exempt from this requirement.
|
||||
|
||||
.. admonition:: Ensure that your login view does not require a login.
|
||||
|
||||
To prevent infinite redirects, ensure you have
|
||||
:ref:`enabled unauthenticated requests
|
||||
<disable-login-required-middleware-for-views>` to your login view.
|
||||
|
||||
**Methods and Attributes**
|
||||
|
||||
.. attribute:: redirect_field_name
|
||||
|
||||
Defaults to ``"next"``.
|
||||
|
||||
.. method:: get_login_url()
|
||||
|
||||
Returns the URL that unauthenticated requests will be redirected to. If
|
||||
defined, this returns the ``login_url`` set on the
|
||||
:func:`~.django.contrib.auth.decorators.login_required` decorator. Defaults
|
||||
to :setting:`settings.LOGIN_URL <LOGIN_URL>`.
|
||||
|
||||
.. method:: get_redirect_field_name()
|
||||
|
||||
Returns the name of the query parameter that contains the URL the user
|
||||
should be redirected to after a successful login. If defined, this returns
|
||||
the ``redirect_field_name`` set on the
|
||||
:func:`~.django.contrib.auth.decorators.login_required` decorator. Defaults
|
||||
to :attr:`redirect_field_name`. If ``None`` is returned, a query parameter
|
||||
won't be added.
|
||||
|
||||
.. class:: RemoteUserMiddleware
|
||||
|
||||
Middleware for utilizing web server provided authentication. See
|
||||
|
||||
@@ -975,9 +975,9 @@ frame includes all rows from the partition to the last row in the set.
|
||||
The accepted values for the ``start`` and ``end`` arguments are ``None``, an
|
||||
integer, or zero. A negative integer for ``start`` results in ``N PRECEDING``,
|
||||
while ``None`` yields ``UNBOUNDED PRECEDING``. In ``ROWS`` mode, a positive
|
||||
integer can be used for ```start`` resulting in ``N FOLLOWING``. Positive
|
||||
integer can be used for ``start`` resulting in ``N FOLLOWING``. Positive
|
||||
integers are accepted for ``end`` and results in ``N FOLLOWING``. In ``ROWS``
|
||||
mode, a negative integer can be used for ```end`` resulting in ``N PRECEDING``.
|
||||
mode, a negative integer can be used for ``end`` resulting in ``N PRECEDING``.
|
||||
For both ``start`` and ``end``, zero will return ``CURRENT ROW``.
|
||||
|
||||
There's a difference in what ``CURRENT ROW`` includes. When specified in
|
||||
@@ -1095,6 +1095,16 @@ calling the appropriate methods on the wrapped expression.
|
||||
:py:data:`NotImplemented` which forces the expression to be computed on
|
||||
the database.
|
||||
|
||||
.. attribute:: set_returning
|
||||
|
||||
.. versionadded:: 5.2
|
||||
|
||||
Tells Django that this expression contains a set-returning function,
|
||||
enforcing subquery evaluation. It's used, for example, to allow some
|
||||
Postgres set-returning functions (e.g. ``JSONB_PATH_QUERY``,
|
||||
``UNNEST``, etc.) to skip optimization and be properly evaluated when
|
||||
annotations spawn rows themselves. Defaults to ``False``.
|
||||
|
||||
.. method:: resolve_expression(query=None, allow_joins=True, reuse=None, summarize=False, for_save=False)
|
||||
|
||||
Provides the chance to do any preprocessing or validation of
|
||||
|
||||
@@ -12,8 +12,8 @@ This document contains all the API references of :class:`Field` including the
|
||||
|
||||
.. seealso::
|
||||
|
||||
If the built-in fields don't do the trick, you can try `django-localflavor
|
||||
<https://github.com/django/django-localflavor>`_ (`documentation
|
||||
If the built-in fields don't do the trick, you can try
|
||||
:pypi:`django-localflavor` (`documentation
|
||||
<https://django-localflavor.readthedocs.io/>`_), which contains assorted
|
||||
pieces of code that are useful for particular countries and cultures.
|
||||
|
||||
@@ -43,13 +43,15 @@ If ``True``, Django will store empty values as ``NULL`` in the database. Default
|
||||
is ``False``.
|
||||
|
||||
Avoid using :attr:`~Field.null` on string-based fields such as
|
||||
:class:`CharField` and :class:`TextField`. If a string-based field has
|
||||
``null=True``, that means it has two possible values for "no data": ``NULL``,
|
||||
and the empty string. In most cases, it's redundant to have two possible values
|
||||
for "no data;" the Django convention is to use the empty string, not
|
||||
``NULL``. One exception is when a :class:`CharField` has both ``unique=True``
|
||||
and ``blank=True`` set. In this situation, ``null=True`` is required to avoid
|
||||
unique constraint violations when saving multiple objects with blank values.
|
||||
:class:`CharField` and :class:`TextField`. The Django convention is to use an
|
||||
empty string, not ``NULL``, as the "no data" state for string-based fields. If a
|
||||
string-based field has ``null=False``, empty strings can still be saved for "no
|
||||
data". If a string-based field has ``null=True``, that means it has two possible
|
||||
values for "no data": ``NULL``, and the empty string. In most cases, it's
|
||||
redundant to have two possible values for "no data". One exception is when a
|
||||
:class:`CharField` has both ``unique=True`` and ``blank=True`` set. In this
|
||||
situation, ``null=True`` is required to avoid unique constraint violations when
|
||||
saving multiple objects with blank values.
|
||||
|
||||
For both string-based and non-string-based fields, you will also need to
|
||||
set ``blank=True`` if you wish to permit empty values in forms, as the
|
||||
@@ -718,8 +720,8 @@ The default form widget for this field is a :class:`~django.forms.TextInput`.
|
||||
The maximum length (in characters) of the field. The ``max_length``
|
||||
is enforced at the database level and in Django's validation using
|
||||
:class:`~django.core.validators.MaxLengthValidator`. It's required for all
|
||||
database backends included with Django except PostgreSQL, which supports
|
||||
unlimited ``VARCHAR`` columns.
|
||||
database backends included with Django except PostgreSQL and SQLite, which
|
||||
supports unlimited ``VARCHAR`` columns.
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -728,6 +730,10 @@ The default form widget for this field is a :class:`~django.forms.TextInput`.
|
||||
``max_length`` for some backends. Refer to the :doc:`database backend
|
||||
notes </ref/databases>` for details.
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
Support for unlimited ``VARCHAR`` columns was added on SQLite.
|
||||
|
||||
.. attribute:: CharField.db_collation
|
||||
|
||||
Optional. The database collation name of the field.
|
||||
@@ -1357,9 +1363,7 @@ following optional arguments:
|
||||
Name of a model field which is auto-populated with the width of the image
|
||||
each time an image object is set.
|
||||
|
||||
Requires the `Pillow`_ library.
|
||||
|
||||
.. _Pillow: https://pillow.readthedocs.io/en/latest/
|
||||
Requires the :pypi:`pillow` library.
|
||||
|
||||
:class:`ImageField` instances are created in your database as ``varchar``
|
||||
columns with a default max length of 100 characters. As with other fields, you
|
||||
@@ -2441,6 +2445,9 @@ Field API reference
|
||||
Returns the default :class:`django.forms.Field` of this field for
|
||||
:class:`~django.forms.ModelForm`.
|
||||
|
||||
If :meth:`~Field.formfield` is overridden to return ``None``, this field
|
||||
is excluded from the :class:`~django.forms.ModelForm`.
|
||||
|
||||
By default, if both ``form_class`` and ``choices_form_class`` are
|
||||
``None``, it uses :class:`~django.forms.CharField`. If the field has
|
||||
:attr:`~django.db.models.Field.choices` and ``choices_form_class``
|
||||
|
||||
@@ -973,3 +973,14 @@ Other attributes
|
||||
since they are yet to be saved. Instances fetched from a ``QuerySet``
|
||||
will have ``adding=False`` and ``db`` set to the alias of the associated
|
||||
database.
|
||||
|
||||
``_is_pk_set()``
|
||||
----------------
|
||||
|
||||
.. method:: Model._is_pk_set()
|
||||
|
||||
.. versionadded:: 5.2
|
||||
|
||||
The ``_is_pk_set()`` method returns whether the model instance's ``pk`` is set.
|
||||
It abstracts the model's primary key definition, ensuring consistent behavior
|
||||
regardless of the specific ``pk`` configuration.
|
||||
|
||||
@@ -1599,9 +1599,7 @@ of the arguments is required, but you should use at least one of them.
|
||||
FROM blog_blog;
|
||||
|
||||
Note that the parentheses required by most database engines around
|
||||
subqueries are not required in Django's ``select`` clauses. Also note
|
||||
that some database backends, such as some MySQL versions, don't support
|
||||
subqueries.
|
||||
subqueries are not required in Django's ``select`` clauses.
|
||||
|
||||
In some rare cases, you might wish to pass parameters to the SQL
|
||||
fragments in ``extra(select=...)``. For this purpose, use the
|
||||
|
||||
@@ -425,10 +425,48 @@ Methods
|
||||
Returns ``True`` if the request is secure; that is, if it was made with
|
||||
HTTPS.
|
||||
|
||||
.. method:: HttpRequest.get_preferred_type(media_types)
|
||||
|
||||
.. versionadded:: 5.2
|
||||
|
||||
Returns the preferred mime type from ``media_types``, based on the
|
||||
``Accept`` header, or ``None`` if the client does not accept any of the
|
||||
provided types.
|
||||
|
||||
Assuming the client sends an ``Accept`` header of
|
||||
``text/html,application/json;q=0.8``:
|
||||
|
||||
.. code-block:: pycon
|
||||
|
||||
>>> request.get_preferred_type(["text/html", "application/json"])
|
||||
"text/html"
|
||||
>>> request.get_preferred_type(["application/json", "text/plain"])
|
||||
"application/json"
|
||||
>>> request.get_preferred_type(["application/xml", "text/plain"])
|
||||
None
|
||||
|
||||
Most browsers send ``Accept: */*`` by default, meaning they don't have a
|
||||
preference, in which case the first item in ``media_types`` would be
|
||||
returned.
|
||||
|
||||
Setting an explicit ``Accept`` header in API requests can be useful for
|
||||
returning a different content type for those consumers only. See
|
||||
:ref:`content-negotiation-example` for an example of returning
|
||||
different content based on the ``Accept`` header.
|
||||
|
||||
.. note::
|
||||
|
||||
If a response varies depending on the content of the ``Accept`` header
|
||||
and you are using some form of caching like Django's
|
||||
:mod:`cache middleware <django.middleware.cache>`, you should decorate
|
||||
the view with :func:`vary_on_headers('Accept')
|
||||
<django.views.decorators.vary.vary_on_headers>` so that the responses
|
||||
are properly cached.
|
||||
|
||||
.. method:: HttpRequest.accepts(mime_type)
|
||||
|
||||
Returns ``True`` if the request ``Accept`` header matches the ``mime_type``
|
||||
argument:
|
||||
Returns ``True`` if the request's ``Accept`` header matches the
|
||||
``mime_type`` argument:
|
||||
|
||||
.. code-block:: pycon
|
||||
|
||||
@@ -436,17 +474,10 @@ Methods
|
||||
True
|
||||
|
||||
Most browsers send ``Accept: */*`` by default, so this would return
|
||||
``True`` for all content types. Setting an explicit ``Accept`` header in
|
||||
API requests can be useful for returning a different content type for those
|
||||
consumers only. See :ref:`content-negotiation-example` of using
|
||||
``accepts()`` to return different content to API consumers.
|
||||
``True`` for all content types.
|
||||
|
||||
If a response varies depending on the content of the ``Accept`` header and
|
||||
you are using some form of caching like Django's :mod:`cache middleware
|
||||
<django.middleware.cache>`, you should decorate the view with
|
||||
:func:`vary_on_headers('Accept')
|
||||
<django.views.decorators.vary.vary_on_headers>` so that the responses are
|
||||
properly cached.
|
||||
See :ref:`content-negotiation-example` for an example of using
|
||||
``accepts()`` to return different content based on the ``Accept`` header.
|
||||
|
||||
.. method:: HttpRequest.read(size=None)
|
||||
.. method:: HttpRequest.readline()
|
||||
|
||||
@@ -3636,6 +3636,7 @@ Email
|
||||
* :setting:`EMAIL_SUBJECT_PREFIX`
|
||||
* :setting:`EMAIL_TIMEOUT`
|
||||
* :setting:`EMAIL_USE_LOCALTIME`
|
||||
* :setting:`EMAIL_USE_SSL`
|
||||
* :setting:`EMAIL_USE_TLS`
|
||||
* :setting:`MANAGERS`
|
||||
* :setting:`SERVER_EMAIL`
|
||||
|
||||
@@ -660,7 +660,6 @@ settings file, the default template engine contains the following context
|
||||
processors::
|
||||
|
||||
[
|
||||
"django.template.context_processors.debug",
|
||||
"django.template.context_processors.request",
|
||||
"django.contrib.auth.context_processors.auth",
|
||||
"django.contrib.messages.context_processors.messages",
|
||||
|
||||
@@ -2883,8 +2883,8 @@ If ``value`` is ``"https://www.example.org/"``, the output will be
|
||||
Converts URLs and email addresses in text into clickable links.
|
||||
|
||||
This template tag works on links prefixed with ``http://``, ``https://``, or
|
||||
``www.``. For example, ``https://goo.gl/aia1t`` will get converted but
|
||||
``goo.gl/aia1t`` won't.
|
||||
``www.``. For example, ``https://djangocon.eu`` will get converted but
|
||||
``djangocon.eu`` won't.
|
||||
|
||||
It also supports domain-only links ending in one of the original top level
|
||||
domains (``.com``, ``.edu``, ``.gov``, ``.int``, ``.mil``, ``.net``, and
|
||||
@@ -2922,6 +2922,17 @@ Django's built-in :tfilter:`escape` filter. The default value for
|
||||
email addresses that contain single quotes (``'``), things won't work as
|
||||
expected. Apply this filter only to plain text.
|
||||
|
||||
.. warning::
|
||||
|
||||
Using ``urlize`` or ``urlizetrunc`` can incur a performance penalty, which
|
||||
can become severe when applied to user controlled values such as content
|
||||
stored in a :class:`~django.db.models.TextField`. You can use
|
||||
:tfilter:`truncatechars` to add a limit to such inputs:
|
||||
|
||||
.. code-block:: html+django
|
||||
|
||||
{{ value|truncatechars:500|urlize }}
|
||||
|
||||
.. templatefilter:: urlizetrunc
|
||||
|
||||
``urlizetrunc``
|
||||
|
||||
@@ -25,6 +25,9 @@ Returns an element for inclusion in ``urlpatterns``. For example::
|
||||
...,
|
||||
]
|
||||
|
||||
``route``
|
||||
---------
|
||||
|
||||
The ``route`` argument should be a string or
|
||||
:func:`~django.utils.translation.gettext_lazy()` (see
|
||||
:ref:`translating-urlpatterns`) that contains a URL pattern. The string
|
||||
@@ -33,16 +36,43 @@ URL and send it as a keyword argument to the view. The angle brackets may
|
||||
include a converter specification (like the ``int`` part of ``<int:section>``)
|
||||
which limits the characters matched and may also change the type of the
|
||||
variable passed to the view. For example, ``<int:section>`` matches a string
|
||||
of decimal digits and converts the value to an ``int``. See
|
||||
of decimal digits and converts the value to an ``int``.
|
||||
|
||||
When processing a request, Django starts at the first pattern in
|
||||
``urlpatterns`` and makes its way down the list, comparing the requested URL
|
||||
against each pattern until it finds one that matches. See
|
||||
:ref:`how-django-processes-a-request` for more details.
|
||||
|
||||
Patterns don't match GET and POST parameters, or the domain name. For example,
|
||||
in a request to ``https://www.example.com/myapp/``, the URLconf will look for
|
||||
``myapp/``. In a request to ``https://www.example.com/myapp/?page=3``, the
|
||||
URLconf will also look for ``myapp/``.
|
||||
|
||||
``view``
|
||||
--------
|
||||
|
||||
The ``view`` argument is a view function or the result of
|
||||
:meth:`~django.views.generic.base.View.as_view` for class-based views. It can
|
||||
also be an :func:`django.urls.include`.
|
||||
also be a :func:`django.urls.include`.
|
||||
|
||||
When Django finds a matching pattern, it calls the specified view function with
|
||||
an :class:`~django.http.HttpRequest` object as the first argument and any
|
||||
"captured" values from the route as keyword arguments.
|
||||
|
||||
``kwargs``
|
||||
----------
|
||||
|
||||
The ``kwargs`` argument allows you to pass additional arguments to the view
|
||||
function or method. See :ref:`views-extra-options` for an example.
|
||||
|
||||
``name``
|
||||
--------
|
||||
|
||||
Naming your URL lets you refer to it unambiguously from elsewhere in Django,
|
||||
especially from within templates. This powerful feature allows you to make
|
||||
global changes to the URL patterns of your project while only touching a single
|
||||
file.
|
||||
|
||||
See :ref:`Naming URL patterns <naming-url-patterns>` for why the ``name``
|
||||
argument is useful.
|
||||
|
||||
|
||||
@@ -699,10 +699,29 @@ escaping HTML.
|
||||
joined using ``sep``. ``sep`` is also passed through
|
||||
:func:`conditional_escape`.
|
||||
|
||||
``args_generator`` should be an iterator that returns the sequence of
|
||||
``args`` that will be passed to :func:`format_html`. For example::
|
||||
``args_generator`` should be an iterator that yields arguments to pass to
|
||||
:func:`format_html`, either sequences of positional arguments or mappings of
|
||||
keyword arguments.
|
||||
|
||||
format_html_join("\n", "<li>{} {}</li>", ((u.first_name, u.last_name) for u in users))
|
||||
For example, tuples can be used for positional arguments::
|
||||
|
||||
format_html_join(
|
||||
"\n",
|
||||
"<li>{} {}</li>",
|
||||
((u.first_name, u.last_name) for u in users),
|
||||
)
|
||||
|
||||
Or dictionaries can be used for keyword arguments::
|
||||
|
||||
format_html_join(
|
||||
"\n",
|
||||
'<li data-id="{id}">{id} {title}</li>',
|
||||
({"id": b.id, "title": b.title} for b in books),
|
||||
)
|
||||
|
||||
.. versionchanged:: 5.2
|
||||
|
||||
Support for mappings in ``args_generator`` was added.
|
||||
|
||||
.. function:: json_script(value, element_id=None, encoder=None)
|
||||
|
||||
@@ -1148,7 +1167,7 @@ For a complete discussion on the usage of the following see the
|
||||
``'es-ar'`` isn't.
|
||||
|
||||
``lang_code`` has a maximum accepted length of 500 characters. A
|
||||
:exc:`ValueError` is raised if ``lang_code`` exceeds this limit and
|
||||
:exc:`LookupError` is raised if ``lang_code`` exceeds this limit and
|
||||
``strict`` is ``True``, or if there is no generic variant and ``strict``
|
||||
is ``False``.
|
||||
|
||||
@@ -1160,10 +1179,10 @@ For a complete discussion on the usage of the following see the
|
||||
|
||||
Raises :exc:`LookupError` if nothing is found.
|
||||
|
||||
.. versionchanged:: 4.2.14
|
||||
.. versionchanged:: 4.2.15
|
||||
|
||||
In older versions, ``lang_code`` values over 500 characters were
|
||||
processed without raising a :exc:`ValueError`.
|
||||
processed without raising a :exc:`LookupError`.
|
||||
|
||||
.. function:: to_locale(language)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user