mirror of
https://github.com/django/django.git
synced 2025-07-24 05:36:15 +00:00
Fixed #26013 -- Moved django.core.urlresolvers to django.urls.
Thanks to Tim Graham for the review.
This commit is contained in:
parent
df3d5b1d73
commit
16411b8400
117 changed files with 961 additions and 922 deletions
|
@ -13,7 +13,7 @@ views for displaying drilldown pages for date-based data.
|
|||
defined as follows in ``myapp/models.py``::
|
||||
|
||||
from django.db import models
|
||||
from django.core.urlresolvers import reverse
|
||||
from django.urls import reverse
|
||||
|
||||
class Article(models.Model):
|
||||
title = models.CharField(max_length=200)
|
||||
|
|
|
@ -15,7 +15,7 @@ editing content:
|
|||
Some of the examples on this page assume that an ``Author`` model has been
|
||||
defined as follows in ``myapp/models.py``::
|
||||
|
||||
from django.core.urlresolvers import reverse
|
||||
from django.urls import reverse
|
||||
from django.db import models
|
||||
|
||||
class Author(models.Model):
|
||||
|
@ -227,7 +227,7 @@ DeleteView
|
|||
**Example myapp/views.py**::
|
||||
|
||||
from django.views.generic.edit import DeleteView
|
||||
from django.core.urlresolvers import reverse_lazy
|
||||
from django.urls import reverse_lazy
|
||||
from myapp.models import Author
|
||||
|
||||
class AuthorDelete(DeleteView):
|
||||
|
|
|
@ -1252,7 +1252,7 @@ subclass::
|
|||
For example::
|
||||
|
||||
from django.contrib import admin
|
||||
from django.core.urlresolvers import reverse
|
||||
from django.urls import reverse
|
||||
|
||||
class PersonAdmin(admin.ModelAdmin):
|
||||
def view_on_site(self, obj):
|
||||
|
@ -2883,9 +2883,9 @@ So - if you wanted to get a reference to the Change view for a particular
|
|||
``Choice`` object (from the polls application) in the default admin, you would
|
||||
call::
|
||||
|
||||
>>> from django.core import urlresolvers
|
||||
>>> from django.urls import reverse
|
||||
>>> c = Choice.objects.get(...)
|
||||
>>> change_url = urlresolvers.reverse('admin:polls_choice_change', args=(c.id,))
|
||||
>>> change_url = reverse('admin:polls_choice_change', args=(c.id,))
|
||||
|
||||
This will find the first registered instance of the admin application
|
||||
(whatever the instance name), and resolve to the view for changing
|
||||
|
@ -2896,8 +2896,7 @@ that instance as a ``current_app`` hint to the reverse call. For example,
|
|||
if you specifically wanted the admin view from the admin instance named
|
||||
``custom``, you would need to call::
|
||||
|
||||
>>> change_url = urlresolvers.reverse('admin:polls_choice_change',
|
||||
... args=(c.id,), current_app='custom')
|
||||
>>> change_url = reverse('admin:polls_choice_change', args=(c.id,), current_app='custom')
|
||||
|
||||
For more details, see the documentation on :ref:`reversing namespaced URLs
|
||||
<topics-http-reversing-url-namespaces>`.
|
||||
|
|
|
@ -300,13 +300,12 @@ Sitemap for static views
|
|||
|
||||
Often you want the search engine crawlers to index views which are neither
|
||||
object detail pages nor flatpages. The solution is to explicitly list URL
|
||||
names for these views in ``items`` and call
|
||||
:func:`~django.core.urlresolvers.reverse` in the ``location`` method of
|
||||
the sitemap. For example::
|
||||
names for these views in ``items`` and call :func:`~django.urls.reverse` in
|
||||
the ``location`` method of the sitemap. For example::
|
||||
|
||||
# sitemaps.py
|
||||
from django.contrib import sitemaps
|
||||
from django.core.urlresolvers import reverse
|
||||
from django.urls import reverse
|
||||
|
||||
class StaticViewSitemap(sitemaps.Sitemap):
|
||||
priority = 0.5
|
||||
|
|
|
@ -53,7 +53,7 @@ This simple example, taken from a hypothetical police beat news site describes
|
|||
a feed of the latest five news items::
|
||||
|
||||
from django.contrib.syndication.views import Feed
|
||||
from django.core.urlresolvers import reverse
|
||||
from django.urls import reverse
|
||||
from policebeat.models import NewsItem
|
||||
|
||||
class LatestEntriesFeed(Feed):
|
||||
|
|
|
@ -84,7 +84,7 @@ Django core exception classes are defined in ``django.core.exceptions``.
|
|||
.. exception:: ViewDoesNotExist
|
||||
|
||||
The :exc:`ViewDoesNotExist` exception is raised by
|
||||
:mod:`django.core.urlresolvers` when a requested view does not exist.
|
||||
:mod:`django.urls` when a requested view does not exist.
|
||||
|
||||
``MiddlewareNotUsed``
|
||||
---------------------
|
||||
|
@ -142,12 +142,18 @@ or model are classified as ``NON_FIELD_ERRORS``. This constant is used
|
|||
as a key in dictionaries that otherwise map fields to their respective
|
||||
list of errors.
|
||||
|
||||
.. currentmodule:: django.core.urlresolvers
|
||||
.. currentmodule:: django.urls
|
||||
|
||||
URL Resolver exceptions
|
||||
=======================
|
||||
|
||||
URL Resolver exceptions are defined in ``django.core.urlresolvers``.
|
||||
URL Resolver exceptions are defined in ``django.urls``.
|
||||
|
||||
.. deprecated:: 1.10
|
||||
|
||||
In older versions, these exceptions are located in
|
||||
``django.core.urlresolvers``. Importing from the old location will continue
|
||||
to work until Django 2.0.
|
||||
|
||||
``Resolver404``
|
||||
---------------
|
||||
|
@ -155,18 +161,17 @@ URL Resolver exceptions are defined in ``django.core.urlresolvers``.
|
|||
.. exception:: Resolver404
|
||||
|
||||
The :exc:`Resolver404` exception is raised by
|
||||
:func:`django.core.urlresolvers.resolve()` if the path passed to
|
||||
``resolve()`` doesn't map to a view. It's a subclass of
|
||||
:class:`django.http.Http404`.
|
||||
:func:`~django.urls.resolve()` if the path passed to ``resolve()`` doesn't
|
||||
map to a view. It's a subclass of :class:`django.http.Http404`.
|
||||
|
||||
``NoReverseMatch``
|
||||
------------------
|
||||
|
||||
.. exception:: NoReverseMatch
|
||||
|
||||
The :exc:`NoReverseMatch` exception is raised by
|
||||
:mod:`django.core.urlresolvers` when a matching URL in your URLconf
|
||||
cannot be identified based on the parameters supplied.
|
||||
The :exc:`NoReverseMatch` exception is raised by :mod:`django.urls` when a
|
||||
matching URL in your URLconf cannot be identified based on the parameters
|
||||
supplied.
|
||||
|
||||
.. currentmodule:: django.db
|
||||
|
||||
|
|
|
@ -672,14 +672,14 @@ For example::
|
|||
def get_absolute_url(self):
|
||||
return "/people/%i/" % self.id
|
||||
|
||||
(Whilst this code is correct and simple, it may not be the most portable way to
|
||||
write this kind of method. The :func:`~django.core.urlresolvers.reverse`
|
||||
function is usually the best approach.)
|
||||
While this code is correct and simple, it may not be the most portable way to
|
||||
to write this kind of method. The :func:`~django.urls.reverse` function is
|
||||
usually the best approach.
|
||||
|
||||
For example::
|
||||
|
||||
def get_absolute_url(self):
|
||||
from django.core.urlresolvers import reverse
|
||||
from django.urls import reverse
|
||||
return reverse('people.views.details', args=[str(self.id)])
|
||||
|
||||
One place Django uses ``get_absolute_url()`` is in the admin app. If an object
|
||||
|
|
|
@ -160,11 +160,11 @@ All attributes should be considered read-only, unless stated otherwise.
|
|||
|
||||
.. attribute:: HttpRequest.resolver_match
|
||||
|
||||
An instance of :class:`~django.core.urlresolvers.ResolverMatch` representing
|
||||
the resolved url. This attribute is only set after url resolving took place,
|
||||
which means it's available in all views but not in middleware methods which
|
||||
are executed before url resolving takes place (like ``process_request``, you
|
||||
can use ``process_view`` instead).
|
||||
An instance of :class:`~django.urls.ResolverMatch` representing the
|
||||
resolved URL. This attribute is only set after URL resolving took place,
|
||||
which means it's available in all views but not in middleware methods
|
||||
which are executed before URL resolving takes place (like
|
||||
``process_request()``, you can use ``process_view()`` instead).
|
||||
|
||||
Attributes set by application code
|
||||
----------------------------------
|
||||
|
@ -175,7 +175,7 @@ application.
|
|||
.. attribute:: HttpRequest.current_app
|
||||
|
||||
The :ttag:`url` template tag will use its value as the ``current_app``
|
||||
argument to :func:`~django.core.urlresolvers.reverse()`.
|
||||
argument to :func:`~django.urls.reverse()`.
|
||||
|
||||
.. attribute:: HttpRequest.urlconf
|
||||
|
||||
|
|
|
@ -1024,8 +1024,8 @@ such as this:
|
|||
The template tag will output the string ``/clients/client/123/``.
|
||||
|
||||
Note that if the URL you're reversing doesn't exist, you'll get an
|
||||
:exc:`~django.core.urlresolvers.NoReverseMatch` exception raised, which will
|
||||
cause your site to display an error page.
|
||||
:exc:`~django.urls.NoReverseMatch` exception raised, which will cause your
|
||||
site to display an error page.
|
||||
|
||||
If you'd like to retrieve a URL without displaying it, you can use a slightly
|
||||
different call::
|
||||
|
|
|
@ -290,8 +290,8 @@ Taking care in ``get_absolute_url()``
|
|||
|
||||
URLs can only contain ASCII characters. If you're constructing a URL from
|
||||
pieces of data that might be non-ASCII, be careful to encode the results in a
|
||||
way that is suitable for a URL. The :func:`~django.core.urlresolvers.reverse`
|
||||
function handles this for you automatically.
|
||||
way that is suitable for a URL. The :func:`~django.urls.reverse` function
|
||||
handles this for you automatically.
|
||||
|
||||
If you're constructing a URL manually (i.e., *not* using the ``reverse()``
|
||||
function), you'll need to take care of the encoding yourself. In this case,
|
||||
|
|
|
@ -1,8 +1,14 @@
|
|||
==============================================
|
||||
``django.core.urlresolvers`` utility functions
|
||||
==============================================
|
||||
=================================
|
||||
``django.urls`` utility functions
|
||||
=================================
|
||||
|
||||
.. module:: django.core.urlresolvers
|
||||
.. module:: django.urls
|
||||
|
||||
.. deprecated:: 1.10
|
||||
|
||||
In older versions, these functions are located in
|
||||
``django.core.urlresolvers``. Importing from the old location will continue
|
||||
to work until Django 2.0.
|
||||
|
||||
reverse()
|
||||
---------
|
||||
|
@ -31,7 +37,7 @@ you can use any of the following to reverse the URL::
|
|||
|
||||
If the URL accepts arguments, you may pass them in ``args``. For example::
|
||||
|
||||
from django.core.urlresolvers import reverse
|
||||
from django.urls import reverse
|
||||
|
||||
def myview(request):
|
||||
return HttpResponseRedirect(reverse('arch-summary', args=[1945]))
|
||||
|
@ -44,7 +50,7 @@ You can also pass ``kwargs`` instead of ``args``. For example::
|
|||
``args`` and ``kwargs`` cannot be passed to ``reverse()`` at the same time.
|
||||
|
||||
If no match can be made, ``reverse()`` raises a
|
||||
:class:`~django.core.urlresolvers.NoReverseMatch` exception.
|
||||
:class:`~django.urls.NoReverseMatch` exception.
|
||||
|
||||
The ``reverse()`` function can reverse a large variety of regular expression
|
||||
patterns for URLs, but not every possible one. The main restriction at the
|
||||
|
@ -103,13 +109,12 @@ corresponding view functions. It has the following signature:
|
|||
.. function:: resolve(path, urlconf=None)
|
||||
|
||||
``path`` is the URL path you want to resolve. As with
|
||||
:func:`~django.core.urlresolvers.reverse`, you don't need to
|
||||
worry about the ``urlconf`` parameter. The function returns a
|
||||
:class:`ResolverMatch` object that allows you
|
||||
to access various meta-data about the resolved URL.
|
||||
:func:`~django.urls.reverse`, you don't need to worry about the ``urlconf``
|
||||
parameter. The function returns a :class:`ResolverMatch` object that allows you
|
||||
to access various metadata about the resolved URL.
|
||||
|
||||
If the URL does not resolve, the function raises a
|
||||
:exc:`~django.core.urlresolvers.Resolver404` exception (a subclass of
|
||||
:exc:`~django.urls.Resolver404` exception (a subclass of
|
||||
:class:`~django.http.Http404`) .
|
||||
|
||||
.. class:: ResolverMatch
|
||||
|
@ -175,10 +180,10 @@ A :class:`ResolverMatch` object can also be assigned to a triple::
|
|||
|
||||
func, args, kwargs = resolve('/some/path/')
|
||||
|
||||
One possible use of :func:`~django.core.urlresolvers.resolve` would be to test
|
||||
whether a view would raise a ``Http404`` error before redirecting to it::
|
||||
One possible use of :func:`~django.urls.resolve` would be to test whether a
|
||||
view would raise a ``Http404`` error before redirecting to it::
|
||||
|
||||
from django.core.urlresolvers import resolve
|
||||
from django.urls import resolve
|
||||
from django.http import HttpResponseRedirect, Http404
|
||||
from django.utils.six.moves.urllib.parse import urlparse
|
||||
|
||||
|
@ -202,12 +207,11 @@ get_script_prefix()
|
|||
|
||||
.. function:: get_script_prefix()
|
||||
|
||||
Normally, you should always use :func:`~django.core.urlresolvers.reverse` to
|
||||
define URLs within your application. However, if your application constructs
|
||||
part of the URL hierarchy itself, you may occasionally need to generate URLs.
|
||||
In that case, you need to be able to find the base URL of the Django project
|
||||
within its Web server (normally, :func:`~django.core.urlresolvers.reverse`
|
||||
takes care of this for you). In that case, you can call
|
||||
``get_script_prefix()``, which will return the script prefix portion of the URL
|
||||
for your Django project. If your Django project is at the root of its web
|
||||
server, this is always ``"/"``.
|
||||
Normally, you should always use :func:`~django.urls.reverse` to define URLs
|
||||
within your application. However, if your application constructs part of the
|
||||
URL hierarchy itself, you may occasionally need to generate URLs. In that
|
||||
case, you need to be able to find the base URL of the Django project within
|
||||
its Web server (normally, :func:`~django.urls.reverse` takes care of this for
|
||||
you). In that case, you can call ``get_script_prefix()``, which will return
|
||||
the script prefix portion of the URL for your Django project. If your Django
|
||||
project is at the root of its web server, this is always ``"/"``.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue