### Navigation

- index
- modules |
- next |
- previous |
- django-registration 1.0 documentation »

# Registration views

In order to allow the utmost flexibility in customizing and supporting different workflows, django-registration makes use of Django’s support for class-based views. Included in django-registration are two base classes which can be subclassed to implement whatever workflow is required.

class `registration.views.``RegistrationView`

  A subclass of Django’s FormView, which provides the infrastructure for supporting user registration.

  Since it’s a subclass of `FormView`, `RegistrationView` has all the usual attributes and methods you can override; however, there is one key difference. In order to support additional customization, `RegistrationView` also passes the `HttpRequest` to most of its methods. Subclasses do need to take this into account, and accept the `request` argument.

  Useful places to override or customize on a `RegistrationView` subclass are:

  `disallowed_url`

    The URL to redirect to when registration is disallowed. Should be a string, the name of a URL pattern. Default value is `registration_disallowed`.

  `form_class`

    The form class to use for user registration. Can be overridden on a per-request basis (see below). Should be the actual class object; by default, this class is `registration.forms.RegistrationForm`.

  `success_url`

    The URL to redirect to after successful registration. Should be a string, the name of a URL pattern, or a 3-tuple of arguments suitable for passing to Django’s redirect shortcut <https://docs.djangoproject.com/en/dev/topics/http/shortcuts/#redirect>. Can be overridden on a per-request basis (see below). Default value is `None`, so that per-request customization is used instead.

  `template_name`

    The template to use for user registration. Should be a string. Default value is `registration/registration_form.html`.

  `get_form_class`(request)

    Select a form class to use on a per-request basis. If not overridden, will use `form_class`. Should be the actual class object.

  `get_success_url`(request, user)

    Return a URL to redirect to after successful registration, on a per-request or per-user basis. If not overridden, will use `success_url`. Should be a string, the name of a URL pattern, or a 3-tuple of arguments suitable for passing to Django’s `redirect` shortcut.

  `registration_allowed`(request)

    Should return a boolean indicating whether user registration is allowed, either in general or for this specific request.

  `register`(request, **cleaned_data)

    Actually perform the business of registering a new user. Receives both the `HttpRequest` object and all of the `cleaned_data` from the registration form. Should return the new user who was just registered.

class `registration.views.``ActivationView`

  A subclass of Django’s TemplateView which provides support for a separate account-activation step, in workflows which require that.

  Useful places to override or customize on an `ActivationView` subclass are:

  `template_name`

    The template to use for user activation. Should be a string. Default value is `registration/activate.html`.

  `activate`(request, *args, **kwargs)

    Actually perform the business of activating a user account. Receives the `HttpRequest` object and any positional or keyword arguments passed to the view. Should return the activated user account if activation is successful, or any value which evaluates `False` in boolean context if activation is unsuccessful.

  `get_success_url`(request, user)

    Return a URL to redirect to after successful registration, on a per-request or per-user basis. If not overridden, will use `success_url`. Should be a string, the name of a URL pattern, or a 3-tuple of arguments suitable for passing to Django’s `redirect` shortcut.

### Navigation

- index
- modules |
- next |
- previous |
- django-registration 1.0 documentation »