[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

@@ -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 <request-middleware>`), 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