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 onFormView
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 ofRegistrationForm
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:
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:
- 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’sreverse_lazy()
helper. Default value is the result of callingreverse_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’sreverse_lazy()
helper. Can be overridden on a per-request basis (see below). Default value isNone
; 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:
- 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 assuccess_url
(see above).- Parameters:
user (django.contrib.auth.models.AbstractUser) – The new user account.
- Return type:
- 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 onFormView
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 youractivate()
method. In the latter case, the exception’smessage
,code
, andparams
will be gathered into a dictionary and injected into the template context as the variableactivation_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’sreverse_lazy()
helper. Can be overridden on a per-request basis (see below). Default value isNone
; 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 assuccess_url
(see above).- Parameters:
user (django.contrib.auth.models.AbstractUser) – The activated user account.
- Return type: