mirror of
https://github.com/django/django.git
synced 2025-09-09 18:49:11 +00:00
Ensured :doc: role uses absolute targets in docs.
This commit is contained in:
Adam Johnson
nessita
parent
ae03f81ffa
commit
56955636e6
@ -25,4 +25,4 @@ Indices, glossary and tables
|
||||
|
||||
* :ref:`genindex`
|
||||
* :ref:`modindex`
|
||||
* :doc:`glossary`
|
||||
* :doc:`/glossary`
|
||||
|
||||
@ -29,8 +29,8 @@ You should also consider how you will handle :doc:`static files
|
||||
:doc:`error reporting</howto/error-reporting>`.
|
||||
|
||||
Finally, before you deploy your application to production, you should run
|
||||
through our :doc:`deployment checklist<checklist>` to ensure that your
|
||||
configurations are suitable.
|
||||
through our :doc:`deployment checklist </howto/deployment/checklist>` to ensure
|
||||
that your configurations are suitable.
|
||||
|
||||
.. _WSGI: https://wsgi.readthedocs.io/en/latest/
|
||||
.. _ASGI: https://asgi.readthedocs.io/en/latest/
|
||||
|
||||
302
docs/index.txt
302
docs/index.txt
@ -12,34 +12,34 @@ First steps
|
||||
Are you new to Django or to programming? This is the place to start!
|
||||
|
||||
* **From scratch:**
|
||||
:doc:`Overview <intro/overview>` |
|
||||
:doc:`Installation <intro/install>`
|
||||
:doc:`Overview </intro/overview>` |
|
||||
:doc:`Installation </intro/install>`
|
||||
|
||||
* **Tutorial:**
|
||||
:doc:`Part 1: Requests and responses <intro/tutorial01>` |
|
||||
:doc:`Part 2: Models and the admin site <intro/tutorial02>` |
|
||||
:doc:`Part 3: Views and templates <intro/tutorial03>` |
|
||||
:doc:`Part 4: Forms and generic views <intro/tutorial04>` |
|
||||
:doc:`Part 5: Testing <intro/tutorial05>` |
|
||||
:doc:`Part 6: Static files <intro/tutorial06>` |
|
||||
:doc:`Part 7: Customizing the admin site <intro/tutorial07>` |
|
||||
:doc:`Part 8: Adding third-party packages <intro/tutorial08>`
|
||||
:doc:`Part 1: Requests and responses </intro/tutorial01>` |
|
||||
:doc:`Part 2: Models and the admin site </intro/tutorial02>` |
|
||||
:doc:`Part 3: Views and templates </intro/tutorial03>` |
|
||||
:doc:`Part 4: Forms and generic views </intro/tutorial04>` |
|
||||
:doc:`Part 5: Testing </intro/tutorial05>` |
|
||||
:doc:`Part 6: Static files </intro/tutorial06>` |
|
||||
:doc:`Part 7: Customizing the admin site </intro/tutorial07>` |
|
||||
:doc:`Part 8: Adding third-party packages </intro/tutorial08>`
|
||||
|
||||
* **Advanced Tutorials:**
|
||||
:doc:`How to write reusable apps <intro/reusable-apps>` |
|
||||
:doc:`Writing your first contribution to Django <intro/contributing>`
|
||||
:doc:`How to write reusable apps </intro/reusable-apps>` |
|
||||
:doc:`Writing your first contribution to Django </intro/contributing>`
|
||||
|
||||
Getting help
|
||||
============
|
||||
|
||||
Having trouble? We'd like to help!
|
||||
|
||||
* Try the :doc:`FAQ <faq/index>` -- it's got answers to many common questions.
|
||||
* Try the :doc:`FAQ </faq/index>` -- it's got answers to many common questions.
|
||||
|
||||
* Looking for specific information? Try the :ref:`genindex`, :ref:`modindex` or
|
||||
the :doc:`detailed table of contents <contents>`.
|
||||
the :doc:`detailed table of contents </contents>`.
|
||||
|
||||
* Not found anything? See :doc:`faq/help` for information on getting support
|
||||
* Not found anything? See :doc:`/faq/help` for information on getting support
|
||||
and asking questions to the community.
|
||||
|
||||
* Report bugs with Django in our `ticket tracker`_.
|
||||
@ -74,46 +74,46 @@ Django provides an abstraction layer (the "models") for structuring and
|
||||
manipulating the data of your web application. Learn more about it below:
|
||||
|
||||
* **Models:**
|
||||
:doc:`Introduction to models <topics/db/models>` |
|
||||
:doc:`Field types <ref/models/fields>` |
|
||||
:doc:`Indexes <ref/models/indexes>` |
|
||||
:doc:`Meta options <ref/models/options>` |
|
||||
:doc:`Model class <ref/models/class>`
|
||||
:doc:`Introduction to models </topics/db/models>` |
|
||||
:doc:`Field types </ref/models/fields>` |
|
||||
:doc:`Indexes </ref/models/indexes>` |
|
||||
:doc:`Meta options </ref/models/options>` |
|
||||
:doc:`Model class </ref/models/class>`
|
||||
|
||||
* **QuerySets:**
|
||||
:doc:`Making queries <topics/db/queries>` |
|
||||
:doc:`QuerySet method reference <ref/models/querysets>` |
|
||||
:doc:`Lookup expressions <ref/models/lookups>`
|
||||
:doc:`Making queries </topics/db/queries>` |
|
||||
:doc:`QuerySet method reference </ref/models/querysets>` |
|
||||
:doc:`Lookup expressions </ref/models/lookups>`
|
||||
|
||||
* **Model instances:**
|
||||
:doc:`Instance methods <ref/models/instances>` |
|
||||
:doc:`Accessing related objects <ref/models/relations>`
|
||||
:doc:`Instance methods </ref/models/instances>` |
|
||||
:doc:`Accessing related objects </ref/models/relations>`
|
||||
|
||||
* **Migrations:**
|
||||
:doc:`Introduction to Migrations<topics/migrations>` |
|
||||
:doc:`Operations reference <ref/migration-operations>` |
|
||||
:doc:`SchemaEditor <ref/schema-editor>` |
|
||||
:doc:`Writing migrations <howto/writing-migrations>`
|
||||
:doc:`Introduction to Migrations</topics/migrations>` |
|
||||
:doc:`Operations reference </ref/migration-operations>` |
|
||||
:doc:`SchemaEditor </ref/schema-editor>` |
|
||||
:doc:`Writing migrations </howto/writing-migrations>`
|
||||
|
||||
* **Advanced:**
|
||||
:doc:`Managers <topics/db/managers>` |
|
||||
:doc:`Raw SQL <topics/db/sql>` |
|
||||
:doc:`Transactions <topics/db/transactions>` |
|
||||
:doc:`Aggregation <topics/db/aggregation>` |
|
||||
:doc:`Search <topics/db/search>` |
|
||||
:doc:`Custom fields <howto/custom-model-fields>` |
|
||||
:doc:`Multiple databases <topics/db/multi-db>` |
|
||||
:doc:`Custom lookups <howto/custom-lookups>` |
|
||||
:doc:`Query Expressions <ref/models/expressions>` |
|
||||
:doc:`Conditional Expressions <ref/models/conditional-expressions>` |
|
||||
:doc:`Database Functions <ref/models/database-functions>`
|
||||
:doc:`Managers </topics/db/managers>` |
|
||||
:doc:`Raw SQL </topics/db/sql>` |
|
||||
:doc:`Transactions </topics/db/transactions>` |
|
||||
:doc:`Aggregation </topics/db/aggregation>` |
|
||||
:doc:`Search </topics/db/search>` |
|
||||
:doc:`Custom fields </howto/custom-model-fields>` |
|
||||
:doc:`Multiple databases </topics/db/multi-db>` |
|
||||
:doc:`Custom lookups </howto/custom-lookups>` |
|
||||
:doc:`Query Expressions </ref/models/expressions>` |
|
||||
:doc:`Conditional Expressions </ref/models/conditional-expressions>` |
|
||||
:doc:`Database Functions </ref/models/database-functions>`
|
||||
|
||||
* **Other:**
|
||||
:doc:`Supported databases <ref/databases>` |
|
||||
:doc:`Legacy databases <howto/legacy-databases>` |
|
||||
:doc:`Providing initial data <howto/initial-data>` |
|
||||
:doc:`Optimize database access <topics/db/optimization>` |
|
||||
:doc:`PostgreSQL specific features <ref/contrib/postgres/index>`
|
||||
:doc:`Supported databases </ref/databases>` |
|
||||
:doc:`Legacy databases </howto/legacy-databases>` |
|
||||
:doc:`Providing initial data </howto/initial-data>` |
|
||||
:doc:`Optimize database access </topics/db/optimization>` |
|
||||
:doc:`PostgreSQL specific features </ref/contrib/postgres/index>`
|
||||
|
||||
The view layer
|
||||
==============
|
||||
@ -123,39 +123,39 @@ processing a user's request and for returning the response. Find all you need
|
||||
to know about views via the links below:
|
||||
|
||||
* **The basics:**
|
||||
:doc:`URLconfs <topics/http/urls>` |
|
||||
:doc:`View functions <topics/http/views>` |
|
||||
:doc:`Shortcuts <topics/http/shortcuts>` |
|
||||
:doc:`Decorators <topics/http/decorators>` |
|
||||
:doc:`Asynchronous Support <topics/async>`
|
||||
:doc:`URLconfs </topics/http/urls>` |
|
||||
:doc:`View functions </topics/http/views>` |
|
||||
:doc:`Shortcuts </topics/http/shortcuts>` |
|
||||
:doc:`Decorators </topics/http/decorators>` |
|
||||
:doc:`Asynchronous Support </topics/async>`
|
||||
|
||||
* **Reference:**
|
||||
:doc:`Built-in Views <ref/views>` |
|
||||
:doc:`Request/response objects <ref/request-response>` |
|
||||
:doc:`TemplateResponse objects <ref/template-response>`
|
||||
:doc:`Built-in Views </ref/views>` |
|
||||
:doc:`Request/response objects </ref/request-response>` |
|
||||
:doc:`TemplateResponse objects </ref/template-response>`
|
||||
|
||||
* **File uploads:**
|
||||
:doc:`Overview <topics/http/file-uploads>` |
|
||||
:doc:`File objects <ref/files/file>` |
|
||||
:doc:`Storage API <ref/files/storage>` |
|
||||
:doc:`Managing files <topics/files>` |
|
||||
:doc:`Custom storage <howto/custom-file-storage>`
|
||||
:doc:`Overview </topics/http/file-uploads>` |
|
||||
:doc:`File objects </ref/files/file>` |
|
||||
:doc:`Storage API </ref/files/storage>` |
|
||||
:doc:`Managing files </topics/files>` |
|
||||
:doc:`Custom storage </howto/custom-file-storage>`
|
||||
|
||||
* **Class-based views:**
|
||||
:doc:`Overview <topics/class-based-views/index>` |
|
||||
:doc:`Built-in display views <topics/class-based-views/generic-display>` |
|
||||
:doc:`Built-in editing views <topics/class-based-views/generic-editing>` |
|
||||
:doc:`Using mixins <topics/class-based-views/mixins>` |
|
||||
:doc:`API reference <ref/class-based-views/index>` |
|
||||
:doc:`Flattened index<ref/class-based-views/flattened-index>`
|
||||
:doc:`Overview </topics/class-based-views/index>` |
|
||||
:doc:`Built-in display views </topics/class-based-views/generic-display>` |
|
||||
:doc:`Built-in editing views </topics/class-based-views/generic-editing>` |
|
||||
:doc:`Using mixins </topics/class-based-views/mixins>` |
|
||||
:doc:`API reference </ref/class-based-views/index>` |
|
||||
:doc:`Flattened index </ref/class-based-views/flattened-index>`
|
||||
|
||||
* **Advanced:**
|
||||
:doc:`Generating CSV <howto/outputting-csv>` |
|
||||
:doc:`Generating PDF <howto/outputting-pdf>`
|
||||
:doc:`Generating CSV </howto/outputting-csv>` |
|
||||
:doc:`Generating PDF </howto/outputting-pdf>`
|
||||
|
||||
* **Middleware:**
|
||||
:doc:`Overview <topics/http/middleware>` |
|
||||
:doc:`Built-in middleware classes <ref/middleware>`
|
||||
:doc:`Overview </topics/http/middleware>` |
|
||||
:doc:`Built-in middleware classes </ref/middleware>`
|
||||
|
||||
The template layer
|
||||
==================
|
||||
@ -165,17 +165,17 @@ information to be presented to the user. Learn how this syntax can be used by
|
||||
designers and how it can be extended by programmers:
|
||||
|
||||
* **The basics:**
|
||||
:doc:`Overview <topics/templates>`
|
||||
:doc:`Overview </topics/templates>`
|
||||
|
||||
* **For designers:**
|
||||
:doc:`Language overview <ref/templates/language>` |
|
||||
:doc:`Built-in tags and filters <ref/templates/builtins>` |
|
||||
:doc:`Humanization <ref/contrib/humanize>`
|
||||
:doc:`Language overview </ref/templates/language>` |
|
||||
:doc:`Built-in tags and filters </ref/templates/builtins>` |
|
||||
:doc:`Humanization </ref/contrib/humanize>`
|
||||
|
||||
* **For programmers:**
|
||||
:doc:`Template API <ref/templates/api>` |
|
||||
:doc:`Custom tags and filters <howto/custom-template-tags>` |
|
||||
:doc:`Custom template backend <howto/custom-template-backend>`
|
||||
:doc:`Template API </ref/templates/api>` |
|
||||
:doc:`Custom tags and filters </howto/custom-template-tags>` |
|
||||
:doc:`Custom template backend </howto/custom-template-backend>`
|
||||
|
||||
Forms
|
||||
=====
|
||||
@ -184,16 +184,16 @@ Django provides a rich framework to facilitate the creation of forms and the
|
||||
manipulation of form data.
|
||||
|
||||
* **The basics:**
|
||||
:doc:`Overview <topics/forms/index>` |
|
||||
:doc:`Form API <ref/forms/api>` |
|
||||
:doc:`Built-in fields <ref/forms/fields>` |
|
||||
:doc:`Built-in widgets <ref/forms/widgets>`
|
||||
:doc:`Overview </topics/forms/index>` |
|
||||
:doc:`Form API </ref/forms/api>` |
|
||||
:doc:`Built-in fields </ref/forms/fields>` |
|
||||
:doc:`Built-in widgets </ref/forms/widgets>`
|
||||
|
||||
* **Advanced:**
|
||||
:doc:`Forms for models <topics/forms/modelforms>` |
|
||||
:doc:`Integrating media <topics/forms/media>` |
|
||||
:doc:`Formsets <topics/forms/formsets>` |
|
||||
:doc:`Customizing validation <ref/forms/validation>`
|
||||
:doc:`Forms for models </topics/forms/modelforms>` |
|
||||
:doc:`Integrating media </topics/forms/media>` |
|
||||
:doc:`Formsets </topics/forms/formsets>` |
|
||||
:doc:`Customizing validation </ref/forms/validation>`
|
||||
|
||||
The development process
|
||||
=======================
|
||||
@ -202,32 +202,32 @@ Learn about the various components and tools to help you in the development and
|
||||
testing of Django applications:
|
||||
|
||||
* **Settings:**
|
||||
:doc:`Overview <topics/settings>` |
|
||||
:doc:`Full list of settings <ref/settings>`
|
||||
:doc:`Overview </topics/settings>` |
|
||||
:doc:`Full list of settings </ref/settings>`
|
||||
|
||||
* **Applications:**
|
||||
:doc:`Overview <ref/applications>`
|
||||
:doc:`Overview </ref/applications>`
|
||||
|
||||
* **Exceptions:**
|
||||
:doc:`Overview <ref/exceptions>`
|
||||
:doc:`Overview </ref/exceptions>`
|
||||
|
||||
* **django-admin and manage.py:**
|
||||
:doc:`Overview <ref/django-admin>` |
|
||||
:doc:`Adding custom commands <howto/custom-management-commands>`
|
||||
:doc:`Overview </ref/django-admin>` |
|
||||
:doc:`Adding custom commands </howto/custom-management-commands>`
|
||||
|
||||
* **Testing:**
|
||||
:doc:`Introduction <topics/testing/index>` |
|
||||
:doc:`Writing and running tests <topics/testing/overview>` |
|
||||
:doc:`Included testing tools <topics/testing/tools>` |
|
||||
:doc:`Advanced topics <topics/testing/advanced>`
|
||||
:doc:`Introduction </topics/testing/index>` |
|
||||
:doc:`Writing and running tests </topics/testing/overview>` |
|
||||
:doc:`Included testing tools </topics/testing/tools>` |
|
||||
:doc:`Advanced topics </topics/testing/advanced>`
|
||||
|
||||
* **Deployment:**
|
||||
:doc:`Overview <howto/deployment/index>` |
|
||||
:doc:`WSGI servers <howto/deployment/wsgi/index>` |
|
||||
:doc:`ASGI servers <howto/deployment/asgi/index>` |
|
||||
:doc:`Deploying static files <howto/static-files/deployment>` |
|
||||
:doc:`Tracking code errors by email <howto/error-reporting>` |
|
||||
:doc:`Deployment checklist <howto/deployment/checklist>`
|
||||
:doc:`Overview </howto/deployment/index>` |
|
||||
:doc:`WSGI servers </howto/deployment/wsgi/index>` |
|
||||
:doc:`ASGI servers </howto/deployment/asgi/index>` |
|
||||
:doc:`Deploying static files </howto/static-files/deployment>` |
|
||||
:doc:`Tracking code errors by email </howto/error-reporting>` |
|
||||
:doc:`Deployment checklist </howto/deployment/checklist>`
|
||||
|
||||
The admin
|
||||
=========
|
||||
@ -235,9 +235,9 @@ The admin
|
||||
Find all you need to know about the automated admin interface, one of Django's
|
||||
most popular features:
|
||||
|
||||
* :doc:`Admin site <ref/contrib/admin/index>`
|
||||
* :doc:`Admin actions <ref/contrib/admin/actions>`
|
||||
* :doc:`Admin documentation generator<ref/contrib/admin/admindocs>`
|
||||
* :doc:`Admin site </ref/contrib/admin/index>`
|
||||
* :doc:`Admin actions </ref/contrib/admin/actions>`
|
||||
* :doc:`Admin documentation generator </ref/contrib/admin/admindocs>`
|
||||
|
||||
Security
|
||||
========
|
||||
@ -245,13 +245,13 @@ Security
|
||||
Security is a topic of paramount importance in the development of web
|
||||
applications and Django provides multiple protection tools and mechanisms:
|
||||
|
||||
* :doc:`Security overview <topics/security>`
|
||||
* :doc:`Disclosed security issues in Django <releases/security>`
|
||||
* :doc:`Clickjacking protection <ref/clickjacking>`
|
||||
* :doc:`Cross Site Request Forgery protection <ref/csrf>`
|
||||
* :doc:`Cryptographic signing <topics/signing>`
|
||||
* :doc:`Security overview </topics/security>`
|
||||
* :doc:`Disclosed security issues in Django </releases/security>`
|
||||
* :doc:`Clickjacking protection </ref/clickjacking>`
|
||||
* :doc:`Cross Site Request Forgery protection </ref/csrf>`
|
||||
* :doc:`Cryptographic signing </topics/signing>`
|
||||
* :ref:`Security Middleware <security-middleware>`
|
||||
* :doc:`Content Security Policy <ref/csp>`
|
||||
* :doc:`Content Security Policy </ref/csp>`
|
||||
|
||||
Internationalization and localization
|
||||
=====================================
|
||||
@ -260,10 +260,10 @@ Django offers a robust internationalization and localization framework to
|
||||
assist you in the development of applications for multiple languages and world
|
||||
regions:
|
||||
|
||||
* :doc:`Overview <topics/i18n/index>` |
|
||||
:doc:`Internationalization <topics/i18n/translation>` |
|
||||
* :doc:`Overview </topics/i18n/index>` |
|
||||
:doc:`Internationalization </topics/i18n/translation>` |
|
||||
:ref:`Localization <how-to-create-language-files>` |
|
||||
:doc:`Localized web UI formatting and form input <topics/i18n/formatting>`
|
||||
:doc:`Localized web UI formatting and form input </topics/i18n/formatting>`
|
||||
* :doc:`Time zones </topics/i18n/timezones>`
|
||||
|
||||
Performance and optimization
|
||||
@ -272,14 +272,14 @@ Performance and optimization
|
||||
There are a variety of techniques and tools that can help get your code running
|
||||
more efficiently - faster, and using fewer system resources.
|
||||
|
||||
* :doc:`Performance and optimization overview <topics/performance>`
|
||||
* :doc:`Performance and optimization overview </topics/performance>`
|
||||
|
||||
Geographic framework
|
||||
====================
|
||||
|
||||
:doc:`GeoDjango <ref/contrib/gis/index>` intends to be a world-class geographic
|
||||
web framework. Its goal is to make it as easy as possible to build GIS web
|
||||
applications and harness the power of spatially enabled data.
|
||||
:doc:`GeoDjango </ref/contrib/gis/index>` intends to be a world-class
|
||||
geographic web framework. Its goal is to make it as easy as possible to build
|
||||
GIS web applications and harness the power of spatially enabled data.
|
||||
|
||||
Common web application tools
|
||||
============================
|
||||
@ -288,36 +288,36 @@ Django offers multiple tools commonly needed in the development of web
|
||||
applications:
|
||||
|
||||
* **Authentication:**
|
||||
:doc:`Overview <topics/auth/index>` |
|
||||
:doc:`Using the authentication system <topics/auth/default>` |
|
||||
:doc:`Password management <topics/auth/passwords>` |
|
||||
:doc:`Customizing authentication <topics/auth/customizing>` |
|
||||
:doc:`API Reference <ref/contrib/auth>`
|
||||
* :doc:`Caching <topics/cache>`
|
||||
* :doc:`Logging <topics/logging>`
|
||||
* :doc:`Sending emails <topics/email>`
|
||||
* :doc:`Syndication feeds (RSS/Atom) <ref/contrib/syndication>`
|
||||
* :doc:`Pagination <topics/pagination>`
|
||||
* :doc:`Messages framework <ref/contrib/messages>`
|
||||
* :doc:`Serialization <topics/serialization>`
|
||||
* :doc:`Sessions <topics/http/sessions>`
|
||||
* :doc:`Sitemaps <ref/contrib/sitemaps>`
|
||||
* :doc:`Static files management <ref/contrib/staticfiles>`
|
||||
* :doc:`Data validation <ref/validators>`
|
||||
:doc:`Overview </topics/auth/index>` |
|
||||
:doc:`Using the authentication system </topics/auth/default>` |
|
||||
:doc:`Password management </topics/auth/passwords>` |
|
||||
:doc:`Customizing authentication </topics/auth/customizing>` |
|
||||
:doc:`API Reference </ref/contrib/auth>`
|
||||
* :doc:`Caching </topics/cache>`
|
||||
* :doc:`Logging </topics/logging>`
|
||||
* :doc:`Sending emails </topics/email>`
|
||||
* :doc:`Syndication feeds (RSS/Atom) </ref/contrib/syndication>`
|
||||
* :doc:`Pagination </topics/pagination>`
|
||||
* :doc:`Messages framework </ref/contrib/messages>`
|
||||
* :doc:`Serialization </topics/serialization>`
|
||||
* :doc:`Sessions </topics/http/sessions>`
|
||||
* :doc:`Sitemaps </ref/contrib/sitemaps>`
|
||||
* :doc:`Static files management </ref/contrib/staticfiles>`
|
||||
* :doc:`Data validation </ref/validators>`
|
||||
|
||||
Other core functionalities
|
||||
==========================
|
||||
|
||||
Learn about some other core functionalities of the Django framework:
|
||||
|
||||
* :doc:`Conditional content processing <topics/conditional-view-processing>`
|
||||
* :doc:`Content types and generic relations <ref/contrib/contenttypes>`
|
||||
* :doc:`Flatpages <ref/contrib/flatpages>`
|
||||
* :doc:`Redirects <ref/contrib/redirects>`
|
||||
* :doc:`Signals <topics/signals>`
|
||||
* :doc:`System check framework <topics/checks>`
|
||||
* :doc:`The sites framework <ref/contrib/sites>`
|
||||
* :doc:`Unicode in Django <ref/unicode>`
|
||||
* :doc:`Conditional content processing </topics/conditional-view-processing>`
|
||||
* :doc:`Content types and generic relations </ref/contrib/contenttypes>`
|
||||
* :doc:`Flatpages </ref/contrib/flatpages>`
|
||||
* :doc:`Redirects </ref/contrib/redirects>`
|
||||
* :doc:`Signals </topics/signals>`
|
||||
* :doc:`System check framework </topics/checks>`
|
||||
* :doc:`The sites framework </ref/contrib/sites>`
|
||||
* :doc:`Unicode in Django </ref/unicode>`
|
||||
|
||||
The Django open-source project
|
||||
==============================
|
||||
@ -326,23 +326,23 @@ Learn about the development process for the Django project itself and about how
|
||||
you can contribute:
|
||||
|
||||
* **Community:**
|
||||
:doc:`Contributing to Django <internals/contributing/index>` |
|
||||
:doc:`The release process <internals/release-process>` |
|
||||
:doc:`Team organization <internals/organization>` |
|
||||
:doc:`The Django source code repository <internals/git>` |
|
||||
:doc:`Security policies <internals/security>` |
|
||||
:doc:`Mailing lists and Forum<internals/mailing-lists>`
|
||||
:doc:`Contributing to Django </internals/contributing/index>` |
|
||||
:doc:`The release process </internals/release-process>` |
|
||||
:doc:`Team organization </internals/organization>` |
|
||||
:doc:`The Django source code repository </internals/git>` |
|
||||
:doc:`Security policies </internals/security>` |
|
||||
:doc:`Mailing lists and Forum </internals/mailing-lists>`
|
||||
|
||||
* **Design philosophies:**
|
||||
:doc:`Overview <misc/design-philosophies>`
|
||||
:doc:`Overview </misc/design-philosophies>`
|
||||
|
||||
* **Documentation:**
|
||||
:doc:`About this documentation <internals/contributing/writing-documentation>`
|
||||
:doc:`About this documentation </internals/contributing/writing-documentation>`
|
||||
|
||||
* **Third-party distributions:**
|
||||
:doc:`Overview <misc/distributions>`
|
||||
:doc:`Overview </misc/distributions>`
|
||||
|
||||
* **Django over time:**
|
||||
:doc:`API stability <misc/api-stability>` |
|
||||
:doc:`Release notes and upgrading instructions <releases/index>` |
|
||||
:doc:`Deprecation Timeline <internals/deprecation>`
|
||||
:doc:`API stability </misc/api-stability>` |
|
||||
:doc:`Release notes and upgrading instructions </releases/index>` |
|
||||
:doc:`Deprecation Timeline </internals/deprecation>`
|
||||
|
||||
@ -4,8 +4,8 @@ Committing code
|
||||
|
||||
This section is addressed to the mergers and to anyone interested in knowing
|
||||
how code gets committed into Django. If you're a community member who wants to
|
||||
contribute code to Django, look at :doc:`writing-code/working-with-git`
|
||||
instead.
|
||||
contribute code to Django, look at
|
||||
:doc:`/internals/contributing/writing-code/working-with-git` instead.
|
||||
|
||||
.. _handling-pull-requests:
|
||||
|
||||
|
||||
@ -54,7 +54,8 @@ Write some documentation
|
||||
|
||||
Django's documentation is great but it can always be improved. Did you find a
|
||||
typo? Do you think that something should be clarified? Go ahead and suggest a
|
||||
documentation patch! See also the guide on :doc:`writing-documentation`.
|
||||
documentation patch! See also the guide on
|
||||
:doc:`/internals/contributing/writing-documentation`.
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@ -387,7 +387,7 @@ Then, you can help out by:
|
||||
several that are useful for triaging tickets and reviewing proposals as
|
||||
suggested above.
|
||||
|
||||
You can also find more :doc:`new-contributors`.
|
||||
You can also find more :doc:`/internals/contributing/new-contributors`.
|
||||
|
||||
.. _Reports page: https://code.djangoproject.com/wiki/Reports
|
||||
|
||||
|
||||
@ -504,6 +504,6 @@ JavaScript style
|
||||
================
|
||||
|
||||
For details about the JavaScript code style used by Django, see
|
||||
:doc:`javascript`.
|
||||
:doc:`/internals/contributing/writing-code/javascript`.
|
||||
|
||||
.. _editorconfig: https://editorconfig.org/
|
||||
|
||||
@ -15,7 +15,8 @@ If you are fixing a really trivial issue, for example changing a word in the
|
||||
documentation, the preferred way to provide the patch is using GitHub pull
|
||||
requests without a Trac ticket.
|
||||
|
||||
See the :doc:`working-with-git` for more details on how to use pull requests.
|
||||
See the :doc:`/internals/contributing/writing-code/working-with-git` for more
|
||||
details on how to use pull requests.
|
||||
|
||||
"Claiming" tickets
|
||||
==================
|
||||
@ -109,19 +110,20 @@ requirements:
|
||||
|
||||
* The code required to fix a problem or add a feature is an essential part
|
||||
of a solution, but it is not the only part. A good fix should also include a
|
||||
:doc:`regression test <unit-tests>` to validate the behavior that has been
|
||||
fixed and to prevent the problem from arising again. Also, if some tickets
|
||||
are relevant to the code that you've written, mention the ticket numbers in
|
||||
some comments in the test so that one can easily trace back the relevant
|
||||
discussions after your patch gets committed, and the tickets get closed.
|
||||
:doc:`regression test </internals/contributing/writing-code/unit-tests>` to
|
||||
validate the behavior that has been fixed and to prevent the problem from
|
||||
arising again. Also, if some tickets are relevant to the code that you've
|
||||
written, mention the ticket numbers in some comments in the test so that one
|
||||
can easily trace back the relevant discussions after your patch gets
|
||||
committed, and the tickets get closed.
|
||||
|
||||
* If the code adds a new feature, or modifies the behavior of an existing
|
||||
feature, the change should also contain documentation.
|
||||
|
||||
When you think your work is ready to be reviewed, send :doc:`a GitHub pull
|
||||
request <working-with-git>`.
|
||||
If you can't send a pull request for some reason, you can also use patches in
|
||||
Trac. When using this style, follow these guidelines.
|
||||
request </internals/contributing/writing-code/working-with-git>`. If you can't
|
||||
send a pull request for some reason, you can also use patches in Trac. When
|
||||
using this style, follow these guidelines.
|
||||
|
||||
* Submit patches in the format returned by the ``git diff`` command.
|
||||
|
||||
|
||||
@ -142,7 +142,7 @@ When you think your work is ready to be pulled into Django, you should create
|
||||
a pull request at GitHub. A good pull request means:
|
||||
|
||||
* commits with one logical change in each, following the
|
||||
:doc:`coding style <coding-style>`,
|
||||
:doc:`coding style </internals/contributing/writing-code/coding-style>`,
|
||||
|
||||
* well-formed messages for each commit: a summary line and then paragraphs
|
||||
wrapped at 72 characters thereafter -- see the :ref:`committing guidelines
|
||||
|
||||
@ -31,7 +31,8 @@ own branch, called ``stable/A.B.x``, and bugfix/security releases will be
|
||||
issued from those branches.
|
||||
|
||||
For more information about how the Django project issues new releases for
|
||||
security purposes, please see :doc:`our security policies <security>`.
|
||||
security purposes, please see :doc:`our security policies
|
||||
</internals/security>`.
|
||||
|
||||
.. glossary::
|
||||
|
||||
|
||||
@ -1436,7 +1436,7 @@ default templates used by the :class:`ModelAdmin` views:
|
||||
The ``delete_queryset()`` method is given the ``HttpRequest`` and a
|
||||
``QuerySet`` of objects to be deleted. Override this method to customize
|
||||
the deletion process for the "delete selected objects" :doc:`action
|
||||
<actions>`.
|
||||
</ref/contrib/admin/actions>`.
|
||||
|
||||
.. method:: ModelAdmin.save_formset(request, form, formset, change)
|
||||
|
||||
@ -2055,7 +2055,7 @@ default templates used by the :class:`ModelAdmin` views:
|
||||
.. method:: ModelAdmin.get_deleted_objects(objs, request)
|
||||
|
||||
A hook for customizing the deletion process of the :meth:`delete_view` and
|
||||
the "delete selected" :doc:`action <actions>`.
|
||||
the "delete selected" :doc:`action </ref/contrib/admin/actions>`.
|
||||
|
||||
The ``objs`` argument is a homogeneous iterable of objects (a ``QuerySet``
|
||||
or a list of model instances) to be deleted, and ``request`` is the
|
||||
|
||||
@ -156,7 +156,7 @@ Geometry Lookups
|
||||
----------------
|
||||
|
||||
Geographic queries with geometries take the following general form (assuming
|
||||
the ``Zipcode`` model used in the :doc:`model-api`):
|
||||
the ``Zipcode`` model used in the :doc:`/ref/contrib/gis/model-api`):
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
@ -192,7 +192,8 @@ used to pass a band index. On the right hand side, a tuple of the raster and
|
||||
band index can be specified.
|
||||
|
||||
This results in the following general form for lookups involving rasters
|
||||
(assuming the ``Elevation`` model used in the :doc:`model-api`):
|
||||
(assuming the ``Elevation`` model used in the
|
||||
:doc:`/ref/contrib/gis/model-api`):
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
@ -234,11 +235,10 @@ Distance Queries
|
||||
Introduction
|
||||
------------
|
||||
|
||||
Distance calculations with spatial data is tricky because, unfortunately,
|
||||
the Earth is not flat. Some distance queries with fields in a geographic
|
||||
coordinate system may have to be expressed differently because of
|
||||
limitations in PostGIS. Please see the :ref:`selecting-an-srid` section
|
||||
in the :doc:`model-api` documentation for more details.
|
||||
Distance calculations with spatial data is tricky because, unfortunately, the
|
||||
Earth is not flat. Some distance queries with fields in a geographic coordinate
|
||||
system may have to be expressed differently because of limitations in PostGIS.
|
||||
Please see the :ref:`selecting-an-srid` section for more details.
|
||||
|
||||
.. _distance-lookups-intro:
|
||||
|
||||
|
||||
@ -85,7 +85,8 @@ queryset is calculated:
|
||||
express the value in the units of your choice. For example,
|
||||
``city.distance.mi`` is the distance value in miles and
|
||||
``city.distance.km`` is the distance value in kilometers. See
|
||||
:doc:`measure` for usage details and the list of :ref:`supported_units`.
|
||||
:doc:`/ref/contrib/gis/measure` for usage details and the list of
|
||||
:ref:`supported_units`.
|
||||
|
||||
``GeometryDistance``
|
||||
--------------------
|
||||
|
||||
@ -22,9 +22,9 @@ familiarize yourself with Django first.
|
||||
|
||||
.. note::
|
||||
|
||||
GeoDjango has additional requirements beyond what Django requires --
|
||||
please consult the :doc:`installation documentation <install/index>`
|
||||
for more details.
|
||||
GeoDjango has additional requirements beyond what Django requires -- please
|
||||
consult the :doc:`installation documentation
|
||||
</ref/contrib/gis/install/index>` for more details.
|
||||
|
||||
This tutorial will guide you through the creation of a geographic web
|
||||
application for viewing the `world borders`_. [#]_ Some of the code
|
||||
@ -49,8 +49,8 @@ Create a Spatial Database
|
||||
Typically no special setup is required, so you can create a database as you
|
||||
would for any other project. We provide some tips for selected databases:
|
||||
|
||||
* :doc:`install/postgis`
|
||||
* :doc:`install/spatialite`
|
||||
* :doc:`/ref/contrib/gis/install/postgis`
|
||||
* :doc:`/ref/contrib/gis/install/spatialite`
|
||||
|
||||
Create a New Project
|
||||
--------------------
|
||||
@ -305,7 +305,7 @@ Importing Spatial Data
|
||||
======================
|
||||
|
||||
This section will show you how to import the world borders shapefile into the
|
||||
database via GeoDjango models using the :doc:`layermapping`.
|
||||
database via GeoDjango models using the :doc:`/ref/contrib/gis/layermapping`.
|
||||
|
||||
There are many different ways to import data into a spatial database --
|
||||
besides the tools included within GeoDjango, you may also use the following:
|
||||
@ -531,11 +531,13 @@ Next, import the ``load`` module, call the ``run`` routine, and watch
|
||||
|
||||
Try ``ogrinspect``
|
||||
------------------
|
||||
|
||||
Now that you've seen how to define geographic models and import data with the
|
||||
:doc:`layermapping`, it's possible to further automate this process with
|
||||
use of the :djadmin:`ogrinspect` management command. The :djadmin:`ogrinspect`
|
||||
command introspects a GDAL-supported vector data source (e.g., a shapefile)
|
||||
and generates a model definition and ``LayerMapping`` dictionary automatically.
|
||||
:doc:`/ref/contrib/gis/layermapping`, it's possible to further automate this
|
||||
process with use of the :djadmin:`ogrinspect` management command. The
|
||||
:djadmin:`ogrinspect` command introspects a GDAL-supported vector data source
|
||||
(e.g., a shapefile) and generates a model definition and ``LayerMapping``
|
||||
dictionary automatically.
|
||||
|
||||
The general usage of the command goes as follows:
|
||||
|
||||
@ -637,10 +639,10 @@ a ``contains`` lookup using the ``pnt_wkt`` as the parameter:
|
||||
Here, you retrieved a ``QuerySet`` with only one model: the border of the
|
||||
United States (exactly what you would expect).
|
||||
|
||||
Similarly, you may also use a :doc:`GEOS geometry object <geos>`.
|
||||
Here, you can combine the ``intersects`` spatial lookup with the ``get``
|
||||
method to retrieve only the ``WorldBorder`` instance for San Marino instead
|
||||
of a queryset:
|
||||
Similarly, you may also use a :doc:`GEOS geometry object
|
||||
</ref/contrib/gis/geos>`. Here, you can combine the ``intersects`` spatial
|
||||
lookup with the ``get`` method to retrieve only the ``WorldBorder`` instance
|
||||
for San Marino instead of a queryset:
|
||||
|
||||
.. code-block:: pycon
|
||||
|
||||
@ -649,8 +651,8 @@ of a queryset:
|
||||
>>> WorldBorder.objects.get(mpoly__intersects=pnt)
|
||||
<WorldBorder: San Marino>
|
||||
|
||||
The ``contains`` and ``intersects`` lookups are just a subset of the
|
||||
available queries -- the :doc:`db-api` documentation has more.
|
||||
The ``contains`` and ``intersects`` lookups are just a subset of the available
|
||||
queries -- the :doc:`/ref/contrib/gis/db-api` documentation has more.
|
||||
|
||||
.. _automatic-spatial-transformations:
|
||||
|
||||
@ -748,7 +750,7 @@ Geographic annotations
|
||||
|
||||
GeoDjango also offers a set of geographic annotations to compute distances and
|
||||
several other operations (intersection, difference, etc.). See the
|
||||
:doc:`functions` documentation.
|
||||
:doc:`/ref/contrib/gis/functions` documentation.
|
||||
|
||||
Putting your data on the map
|
||||
============================
|
||||
|
||||
@ -942,8 +942,8 @@ Configuring the rendering of a form's widgets
|
||||
|
||||
.. attribute:: Form.default_renderer
|
||||
|
||||
Specifies the :doc:`renderer <renderers>` to use for the form. Defaults to
|
||||
``None`` which means to use the default renderer specified by the
|
||||
Specifies the :doc:`renderer </ref/forms/renderers>` to use for the form.
|
||||
Defaults to ``None`` which means to use the default renderer specified by the
|
||||
:setting:`FORM_RENDERER` setting.
|
||||
|
||||
You can set this as a class attribute when declaring your form or use the
|
||||
@ -1070,9 +1070,9 @@ Customizing the error list format
|
||||
|
||||
.. attribute:: renderer
|
||||
|
||||
Specifies the :doc:`renderer <renderers>` to use for ``ErrorList``.
|
||||
Defaults to ``None`` which means to use the default renderer
|
||||
specified by the :setting:`FORM_RENDERER` setting.
|
||||
Specifies the :doc:`renderer </ref/forms/renderers>` to use for
|
||||
``ErrorList``. Defaults to ``None`` which means to use the default
|
||||
renderer specified by the :setting:`FORM_RENDERER` setting.
|
||||
|
||||
.. attribute:: field_id
|
||||
|
||||
|
||||
@ -215,27 +215,28 @@ messages during filesystem inspection and event subscription processes.
|
||||
``django.contrib.auth``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
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.
|
||||
Log messages related to :doc:`/ref/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``
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Log messages related to :doc:`contrib/gis/index` at various points: during the
|
||||
loading of external GeoSpatial libraries (GEOS, GDAL, etc.) and when reporting
|
||||
errors. Each ``ERROR`` log record includes the caught exception and relevant
|
||||
contextual data.
|
||||
Log messages related to :doc:`/ref/contrib/gis/index` at various points: during
|
||||
the loading of external GeoSpatial libraries (GEOS, GDAL, etc.) and when
|
||||
reporting errors. Each ``ERROR`` log record includes the caught exception and
|
||||
relevant contextual data.
|
||||
|
||||
.. _django-dispatch-logger:
|
||||
|
||||
``django.dispatch``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This logger is used in :doc:`signals`, specifically within the
|
||||
This logger is used in :doc:`/ref/signals`, specifically within the
|
||||
:mod:`~django.dispatch.Signal` class, to report issues when dispatching a
|
||||
signal to a connected receiver. The ``ERROR`` log record includes the caught
|
||||
exception as ``exc_info`` and adds the following extra context:
|
||||
|
||||
@ -6,9 +6,9 @@ Conditional Expressions
|
||||
|
||||
Conditional expressions let you use :keyword:`if` ... :keyword:`elif` ...
|
||||
:keyword:`else` logic within filters, annotations, aggregations, and updates. A
|
||||
conditional expression evaluates a series of conditions for each row of a
|
||||
table and returns the matching result expression. Conditional expressions can
|
||||
also be combined and nested like other :doc:`expressions <expressions>`.
|
||||
conditional expression evaluates a series of conditions for each row of a table
|
||||
and returns the matching result expression. Conditional expressions can also be
|
||||
combined and nested like other :doc:`expressions </ref/models/expressions>`.
|
||||
|
||||
The conditional expression classes
|
||||
==================================
|
||||
|
||||
@ -7,8 +7,8 @@ Database Functions
|
||||
|
||||
The classes documented below provide a way for users to use functions provided
|
||||
by the underlying database as annotations, aggregations, or filters in Django.
|
||||
Functions are also :doc:`expressions <expressions>`, so they can be used and
|
||||
combined with other expressions like :ref:`aggregate functions
|
||||
Functions are also :doc:`expressions </ref/models/expressions>`, so they can be
|
||||
used and combined with other expressions like :ref:`aggregate functions
|
||||
<aggregation-functions>`.
|
||||
|
||||
We'll be using the following model in examples of each function::
|
||||
|
||||
@ -340,7 +340,8 @@ extra attribute ``field_lower`` produced, roughly, from the following SQL:
|
||||
...
|
||||
LOWER("db_table"."field") as "field_lower"
|
||||
|
||||
See :doc:`database-functions` for a list of built-in database functions.
|
||||
See :doc:`/ref/models/database-functions` for a list of built-in database
|
||||
functions.
|
||||
|
||||
The ``Func`` API is as follows:
|
||||
|
||||
@ -582,7 +583,7 @@ Conditional expressions
|
||||
|
||||
Conditional expressions allow you to use :keyword:`if` ... :keyword:`elif` ...
|
||||
:keyword:`else` logic in queries. Django natively supports SQL ``CASE``
|
||||
expressions. For more details see :doc:`conditional-expressions`.
|
||||
expressions. For more details see :doc:`/ref/models/conditional-expressions`.
|
||||
|
||||
``Subquery()`` expressions
|
||||
--------------------------
|
||||
|
||||
@ -332,7 +332,8 @@ Models
|
||||
|
||||
* :class:`~django.db.models.ImageField` now has a default
|
||||
:data:`~django.core.validators.validate_image_file_extension` validator.
|
||||
(This validator moved to the form field in :doc:`Django 1.11.2 <1.11.2>`.)
|
||||
(This validator moved to the form field in :doc:`Django 1.11.2
|
||||
</releases/1.11.2>`.)
|
||||
|
||||
* Added support for time truncation to
|
||||
:class:`~django.db.models.functions.Trunc` functions.
|
||||
|
||||
@ -266,7 +266,7 @@ and in Django 1.5 will raise an ``ImproperlyConfigured`` exception.
|
||||
Everything else
|
||||
---------------
|
||||
|
||||
Django :doc:`1.1 <1.1>` and :doc:`1.2 <1.2>` added
|
||||
Django :doc:`1.1 </releases/1.1>` and :doc:`1.2 </releases/1.2>` added
|
||||
lots of big ticket items to Django, like multiple-database support,
|
||||
model validation, and a session-based messages framework. However,
|
||||
this focus on big features came at the cost of lots of smaller
|
||||
|
||||
@ -75,7 +75,7 @@ models defined in your installed apps.
|
||||
Usage
|
||||
=====
|
||||
|
||||
:doc:`Using Django's default implementation <default>`
|
||||
:doc:`Using Django's default implementation </topics/auth/default>`
|
||||
|
||||
* :ref:`Working with User objects <user-objects>`
|
||||
* :ref:`Permissions and authorization <topic-authorization>`
|
||||
@ -84,6 +84,6 @@ Usage
|
||||
|
||||
:doc:`API reference for the default implementation </ref/contrib/auth>`
|
||||
|
||||
:doc:`Customizing Users and authentication <customizing>`
|
||||
:doc:`Customizing Users and authentication </topics/auth/customizing>`
|
||||
|
||||
:doc:`Password management in Django <passwords>`
|
||||
:doc:`Password management in Django </topics/auth/passwords>`
|
||||
|
||||
@ -5,8 +5,8 @@ Using mixins with class-based views
|
||||
.. caution::
|
||||
|
||||
This is an advanced topic. A working knowledge of :doc:`Django's
|
||||
class-based views<index>` is advised before exploring these
|
||||
techniques.
|
||||
class-based views </topics/class-based-views/index>` is advised before
|
||||
exploring these techniques.
|
||||
|
||||
Django's built-in class-based views provide a lot of functionality,
|
||||
but some of it you may want to use separately. For instance, you may
|
||||
@ -120,9 +120,9 @@ but the main one that most people are going to use is
|
||||
``<app_label>/<model_name>_detail.html``. The ``_detail`` part can be changed
|
||||
by setting
|
||||
:attr:`~django.views.generic.detail.SingleObjectTemplateResponseMixin.template_name_suffix`
|
||||
on a subclass to something else. (For instance, the :doc:`generic edit
|
||||
views<generic-editing>` use ``_form`` for create and update views, and
|
||||
``_confirm_delete`` for delete views.)
|
||||
on a subclass to something else. (For instance, the :doc:`generic edit views
|
||||
</topics/class-based-views/generic-editing>` use ``_form`` for create and
|
||||
update views, and ``_confirm_delete`` for delete views.)
|
||||
|
||||
``ListView``: working with many Django objects
|
||||
----------------------------------------------
|
||||
@ -213,8 +213,8 @@ in the subclass. However if we want our processing to work on a particular
|
||||
object, identified from the URL, we'll want the functionality provided by
|
||||
:class:`~django.views.generic.detail.SingleObjectMixin`.
|
||||
|
||||
We'll demonstrate this with the ``Author`` model we used in the
|
||||
:doc:`generic class-based views introduction<generic-display>`.
|
||||
We'll demonstrate this with the ``Author`` model we used in the :doc:`generic
|
||||
class-based views introduction </topics/class-based-views/generic-display>`.
|
||||
|
||||
.. code-block:: python
|
||||
:caption: ``views.py``
|
||||
@ -390,11 +390,11 @@ increasingly complex as you try to do so, and a good rule of thumb is:
|
||||
|
||||
.. hint::
|
||||
|
||||
Each of your views should use only mixins or views from one of the
|
||||
groups of generic class-based views: :doc:`detail,
|
||||
list<generic-display>`, :doc:`editing<generic-editing>` and
|
||||
date. For example it's fine to combine
|
||||
:class:`TemplateView` (built in view) with
|
||||
Each of your views should use only mixins or views from one of the groups
|
||||
of generic class-based views: :doc:`detail, list
|
||||
</topics/class-based-views/generic-display>`, :doc:`editing
|
||||
</topics/class-based-views/generic-editing>` and date. For example it's
|
||||
fine to combine :class:`TemplateView` (built in view) with
|
||||
:class:`~django.views.generic.list.MultipleObjectMixin` (generic list), but
|
||||
you're likely to have problems combining ``SingleObjectMixin`` (generic
|
||||
detail) with ``MultipleObjectMixin`` (generic list).
|
||||
|
||||
@ -22,11 +22,11 @@ it should be doing.
|
||||
|
||||
The preferred way to write tests in Django is using the :mod:`unittest` module
|
||||
built-in to the Python standard library. This is covered in detail in the
|
||||
:doc:`overview` document.
|
||||
:doc:`/topics/testing/overview` document.
|
||||
|
||||
You can also use any *other* Python test framework; Django provides an API and
|
||||
tools for that kind of integration. They are described in the
|
||||
:ref:`other-testing-frameworks` section of :doc:`advanced`.
|
||||
:ref:`other-testing-frameworks` section of :doc:`/topics/testing/advanced`.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user