Base view classes

In order to allow 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 many types of registration workflows.

The built-in workflows in django-registration provide their own subclasses of these views, and the documentation for those workflows will indicate customization points specific to those subclasses. The following reference covers useful attributes and methods of the base classes, for use in writing your own custom registration workflows.

class django_registration.views.RegistrationView(**kwargs)[source]

Base class for user registration views.

This is a FormView, so any attributes/methods which can be overridden on FormView can also be overridden here.

One custom method here must be implemented by subclasses:

register(form)[source]

Subclasses must override this method.

Implement your registration logic here. form will be the (already-validated) form filled out by the user during the registration process (i.e., a valid instance of RegistrationForm or a subclass of it).

This method should return the newly-registered user instance, and should send the signal django_registration.signals.user_registered. Note that this is not automatically done for you when writing your own custom subclass, so you must send this signal manually.

Parameters:

form (django_registration.forms.RegistrationForm) – The registration form to use.

Return type:

django.contrib.auth.models.AbstractUser

Useful optional places to override or customize on subclasses are:

registration_allowed()[source]

Indicate whether user registration is allowed, either in general or for this specific request. Default value is the value of the setting REGISTRATION_OPEN.

Return type:

bool

disallowed_url

The URL to redirect to when registration is disallowed. Can be a hard-coded string, the string resulting from calling Django’s reverse() helper, or the lazy object produced by Django’s reverse_lazy() helper. Default value is the result of calling reverse_lazy() with the URL name '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 django_registration.forms.RegistrationForm.

success_url

The URL to redirect to after successful registration. Can be a hard-coded string, the string resulting from calling Django’s reverse() helper, or the lazy object produced by Django’s reverse_lazy() helper. Can be overridden on a per-request basis (see below). Default value is None; subclasses must override and provide this.

template_name

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

get_form_class()

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

Return type:

django_registration.forms.RegistrationForm

get_success_url(user)[source]

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 return a value of the same type as success_url (see above).

Parameters:

user (django.contrib.auth.models.AbstractUser) – The new user account.

Return type:

str

class django_registration.views.ActivationView(**kwargs)[source]

Base class for user activation views.

This is a FormView, so any attributes/methods which can be overridden on FormView can also be overridden here.

There are two opportunities to raise errors here: they can be raised as validation errors in the form, or raised via ActivationError in your activate() method. In the latter case, the exception’s message, code, and params will be gathered into a dictionary and injected into the template context as the variable activation_error.

Two custom methods must be implemented by subclasses:

activate(form)[source]

Subclasses must override this method.

Attempt to activate the user account from the given form. Should either return the activated user account, or raise ActivationError.

get_activation_data(request)[source]

Subclasses must override this method.

Return the initial activation data for populating the activation form (for example, by reading an activation key from a querystring parameter)

Useful places to override or customize on a subclass are:

success_url

The URL to redirect to after successful activation. Can be a hard-coded string, the string resulting from calling Django’s reverse() helper, or the lazy object produced by Django’s reverse_lazy() helper. Can be overridden on a per-request basis (see below). Default value is None; subclasses must override and provide this.

template_name

The template to use on HTTP GET and on activation failures. Should be a string. Default value is 'django_registration/activation_form.html'.

get_success_url(user)[source]

Return a URL to redirect to after successful activation, on a per-request or per-user basis. If not overridden, will use success_url. Should return a value of the same type as success_url (see above).

Parameters:

user (django.contrib.auth.models.AbstractUser) – The activated user account.

Return type:

str