Commits

James Bennett committed afdaf78

URLConf -> URLconf to match Django style guide.

  • Participants
  • Parent commits c79d544

Comments (0)

Files changed (6)

File docs/backend-api.rst

 import path to the backend class to be used. So, for example, to use
 the default backend, you'd pass the string
 ``'registration.backends.default.DefaultBackend'`` as the value of the
-``backend`` argument (and the default URLConf included with that
+``backend`` argument (and the default URLconf included with that
 backend does so). The specified backend class will then be imported
 and instantiated (by calling its constructor with no arguments), and
 the resulting instance will be used for all backend-specific

File docs/quickstart.rst

 ~~~~~~~~~~~~~~~
 
 The :ref:`default backend <default-backend>` includes a Django
-``URLConf`` which sets up URL patterns for :ref:`the views in
+``URLconf`` which sets up URL patterns for :ref:`the views in
 django-registration <views>`, as well as several useful views in
 ``django.contrib.auth`` (e.g., login, logout, password
-change/reset). This ``URLConf`` can be found at
+change/reset). This ``URLconf`` can be found at
 ``registration.backends.default.urls``, and so can simply be included
 in your project's root URL configuration. For example, to place the
 URLs under the prefix ``/accounts/``, you could add the following to
-your project's root ``URLConf``::
+your project's root ``URLconf``::
 
     (r'^accounts/', include('registration.backends.default.urls')),
 
 templates should simply output plain text rather than HTML.
 
 To make use of the views from ``django.contrib.auth`` (which are set
-up for you by the default URLConf mentioned above), you will also need
+up for you by the default URLconf mentioned above), you will also need
 to create the templates required by those views. Consult `the
 documentation for Django's authentication system
 <http://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.views.login>`_

File docs/upgrade.rst

 
 If you're upgrading from an older release of django-registration, and
 if you were using the default setup (i.e., the included default
-URLConf and no custom URL patterns or custom arguments to views), you
+URLconf and no custom URL patterns or custom arguments to views), you
 will not need to make any immediate changes. However, the old default
-URLConf has been deprecated and will be removed in version 1.0 of
+URLconf has been deprecated and will be removed in version 1.0 of
 django-registration, so it is recommended that you begin migrating
 now. To do so, change any use of ``registration.urls`` to
 ``registration.backends.default.urls``. For example, if you had the
-following in your root URLConf::
+following in your root URLconf::
 
     (r'^accounts/', include('registration.urls')),
 
 significantly as of django-registration |version|. Both views now
 require the keyword argument ``backend``, which specifies the
 :ref:`registration backend <backend-api>` to use, and so any URL
-pattern for these views must supply that argument.
+pattern for these views must supply that argument. The URLconf
+provided with the default backend properly passes this argument.
 
 The ``profile_callback`` argument of the
 :func:`~registration.views.register` view has been removed; the
 The :func:`~registration.views.activate` view now issues a redirect
 upon successful activation; in :ref:`the default backend
 <default-backend>` this is to the URL pattern named
-``registration_activation_complete``. On unsuccessful activation, the
-``activate()`` view still displays a template, but its context has
-changed: the context will simply consist of any keyword arguments
-captured in the URL and passed to the view.
+``registration_activation_complete``; in the default setup, this will
+redirect to a view which renders the template
+``registration/activation_complete.html``, and so this template should
+be present when using the default backend and default
+configuration. Other backends can specify the location to redirect to
+through their ``post_activation_redirect()`` method, and this can be
+overridden on a case-by-case basis by passing the (new) keyword
+argument ``success_url`` to the :func:`~registration.views.activate`
+view. On unsuccessful activation, the ``activate()`` view still
+displays the same template, but its context has changed: the context
+will simply consist of any keyword arguments captured in the URL and
+passed to the view.
 
 
 Changes to registration forms

File registration/backends/default/urls.py

 """
-URLConf for registration and activation, using django-registration's
+URLconf for registration and activation, using django-registration's
 default backend.
 
 If the default behavior of these views is acceptable to you, simply
-use a line like this in your root URLConf to set up the default URLs
+use a line like this in your root URLconf to set up the default URLs
 for registration::
 
     (r'^accounts/', include('registration.backends.default.urls')),

File registration/tests/urls.py

 
 You should not attempt to use these URLs in any sort of real or
 development environment; instead, use
-``registration/backends/default/urls.py``. This URLConf includes those
+``registration/backends/default/urls.py``. This URLconf includes those
 URLs, and also adds several additional URLs which serve no purpose
 other than to test that optional keyword arguments are properly
 handled.

File registration/urls.py

 """
-Backwards-compatible URLConf for existing django-registration
+Backwards-compatible URLconf for existing django-registration
 installs; this allows the standard ``include('registration.urls')`` to
 continue working, but that usage is deprecated and will be removed for
 django-registration 1.0. For new installs, use