From 4b752d6490722568789470aec883224df1bc49b1 Mon Sep 17 00:00:00 2001 From: Timo Graham Date: Fri, 26 Nov 2010 13:27:28 +0000 Subject: [PATCH] [1.2.X] Fixes #14743 - Add sphinx links and other cleanups to topics/http/urls.txt. Thanks adamv for the patch. Backport of applicable portions of 14705 from trunk. git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.2.X@14706 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/topics/http/urls.txt | 34 +++++++++++++++++++--------------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt index 572deb770a..f5d8c642eb 100644 --- a/docs/topics/http/urls.txt +++ b/docs/topics/http/urls.txt @@ -37,14 +37,14 @@ When a user requests a page from your Django-powered site, this is the algorithm the system follows to determine which Python code to execute: 1. Django determines the root URLconf module to use. Ordinarily, - this is the value of the ``ROOT_URLCONF`` setting, but if the incoming + this is the value of the :setting:`ROOT_URLCONF` setting, but if the incoming ``HttpRequest`` object has an attribute called ``urlconf`` (set by middleware :ref:`request processing `), its value - will be used in place of the ``ROOT_URLCONF`` setting. + will be used in place of the :setting:`ROOT_URLCONF` setting. 2. Django loads that Python module and looks for the variable ``urlpatterns``. This should be a Python list, in the format returned by - the function ``django.conf.urls.defaults.patterns()``. + the function :func:`django.conf.urls.defaults.patterns`. 3. Django runs through each URL pattern, in order, and stops at the first one that matches the requested URL. @@ -174,12 +174,14 @@ Syntax of the urlpatterns variable ================================== ``urlpatterns`` should be a Python list, in the format returned by the function -``django.conf.urls.defaults.patterns()``. Always use ``patterns()`` to create +:func:`django.conf.urls.defaults.patterns`. Always use ``patterns()`` to create the ``urlpatterns`` variable. Convention is to use ``from django.conf.urls.defaults import *`` at the top of your URLconf. This gives your module access to these objects: +.. module:: django.conf.urls.defaults + patterns -------- @@ -436,10 +438,11 @@ directly the pattern list as returned by `patterns`_ instead. For example:: This approach can be seen in use when you deploy an instance of the Django Admin application. The Django Admin is deployed as instances of a -:class:`AdminSite`; each :class:`AdminSite` instance has an attribute -``urls`` that returns the url patterns available to that instance. It is this -attribute that you ``include()`` into your projects ``urlpatterns`` when you -deploy the admin instance. +:class:`~django.contrib.admin.AdminSite`; each +:class:`~django.contrib.admin.AdminSite` instance has an attribute ``urls`` +that returns the url patterns available to that instance. It is this attribute +that you ``include()`` into your projects ``urlpatterns`` when you deploy the +admin instance. .. _`Django Web site`: http://www.djangoproject.com/ @@ -507,9 +510,9 @@ a 3-tuple containing:: This will include the nominated URL patterns into the given application and instance namespace. For example, the ``urls`` attribute of Django's -:class:`AdminSite` object returns a 3-tuple that contains all the patterns in -an admin site, plus the name of the admin instance, and the application -namespace ``admin``. +:class:`~django.contrib.admin.AdminSite` object returns a 3-tuple that contains +all the patterns in an admin site, plus the name of the admin instance, and the +application namespace ``admin``. Once you have defined namespaced URLs, you can reverse them. For details on reversing namespaced urls, see the documentation on :ref:`reversing namespaced @@ -830,15 +833,16 @@ URL paths to the corresponding view functions. It has the following signature: .. function:: resolve(path, urlconf=None) -``path`` is the URL path you want to resolve. As with ``reverse()`` above, you -don't need to worry about the ``urlconf`` parameter. The function returns the -triple (view function, arguments, keyword arguments). +``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 +the triple (view function, arguments, keyword arguments). If the URL does not resolve, the function raises an :class:`~django.http.Http404` exception. For example, it can be used for testing if a view would raise a ``Http404`` -error before redirecting to it:: +error before redirecting to it: from urlparse import urlparse from django.core.urlresolvers import resolve