Commits

James Bennett committed 7dd9e26

More documentation.

  • Participants
  • Parent commits a5e4589

Comments (0)

Files changed (4)

File docs/backend-api.rst

 After creating the new user account, this method should create or
 obtain an instance of ``django.contrib.auth.models.User`` representing
 that account. It should then send the signal
-``registration.signals.user_registered``, with three arguments:
+:data:`registration.signals.user_registered`, with three arguments:
 
 ``sender``
     The backend class (e.g., ``self.__class__``).
 If the account is successfully activated, this method should create or
 obtain an instance of ``django.contrib.auth.models.User`` representing
 the activated account. It should then send the signal
-``registration.signals.user_activated``, with three arguments:
+:data:`registration.signals.user_activated`, with three arguments:
 
 ``sender``
     The backend class.

File docs/index.rst

    
    quickstart
    backend-api
+   signals
    views
    upgrade

File docs/signals.rst

+.. _signals:
+.. module: registration.signals
+
+
+Custom signals used by django-registration
+==========================================
+
+Much of django-registration's customizability comes through the
+ability to write and use :ref:`registration backends <backend-api>`
+implementing different workflows for user registration. However, there
+are many cases where only a small bit of additional logic needs to be
+injected into the registration process, and writing a custom backend
+to support this represents an unnecessary amount of work. A more
+lightweight customization option is provided through two custom
+signals which backends are required to send at specific points during
+the registration process; functions listening for these signals can
+then add whatever logic is needed.
+
+For general documentation on signals and the Django dispatcher,
+consult `Django's signals documentation
+<http://docs.djangoproject.com/en/dev/topics/signals/>`_. This
+documentation assumes that you are familiar with how signals work and
+the process of writing and connecting functions which will listen for
+signals.
+
+
+.. data:: registration.signals.user_activated
+
+   Sent when a user account is activated (not applicable to all
+   backends). Provides the following arguments:
+
+   ``sender``
+       The backend class used to activate the user.
+
+   ``user``
+        An instance of ``django.contrib.auth.models.User``
+        representing the activated account.
+
+   ``request``
+       The ``HttpRequest`` in which the account was activated.
+
+
+.. data:: registration.signals.user_registered
+
+   Sent when a new user account is registered. Provides the following
+   arguments:
+
+   ``sender``
+       The backend class used to register the account.
+
+   ``user``
+        An instance of ``django.contrib.auth.models.User``
+        representing the new account.
+
+   ``request``
+        The ``HttpRequest`` in which the new account was registered.

File docs/upgrade.rst

 
 The ``profile_callback`` argument of the ``register`` view has been
 removed; the functionality it provided can now be implemented easily
-via a custom backend, or by connecting listeners to the signals sent
-during the registration process.
+via a custom backend, or by connecting listeners to :ref:`the signals
+sent during the registration process <signals>`.
 
 Changes to registration forms
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 expected to implement a ``save()`` method which would create the new
 user account. This is no longer the case; creating the account is
 handled by the backend, and so any custom logic should be moved into a
-custom backend, or by connecting listeners to the signals sent during
-the registration process.
+custom backend, or by connecting listeners to :ref:`the signals sent
+during the registration process <signals>`.
+
+Changes to the ``RegistrationProfile`` model
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``RegistrationProfile.objects.create_inactive_user()`` now
+has an additional required argument: ``site``. This allows
+django-registration to easily be used regardless of whether
+``django.contrib.sites`` is installed, since a ``RequestSite`` object
+can be passed in place of a regular ``Site`` object.
+
+The :data:`~registration.signals.user_registered` signal is no longer
+sent by ``RegistrationProfile.objects.create_inactive_user()``, and
+the :data:`~registration.signals.user_activated` signal is no longer
+sent by ``RegistrationProfile.objects.activate_user()``; these signals
+are now sent by the backend after these methods have been called.
+
+The sending of activation emails has been factored out of
+``RegistrationProfile.objects.create_inactive_user()``, and now exists
+as the method ``send_activation_email()`` on instances of
+``RegistrationProfile``.