Today I encountered the exact same problem for a similar use case. However, I had to deal with a class-based views. Class-based views allow inheriting attributes and methods thus making it easier to reuse code in a neat manner.
I will answer your question by discussing the code needed for creating a profile page for users. On this page, they can update their personal information. However, I wanted to show an email field without allowing the user to change the information.
Yes, I could have just left out the email field but my OCD would not allow it.
In the example below I used a form class in combination with the disabled = True method. This code is tested on Django==2.2.7.
# form class in forms.py
# Alter import User if you have created your own User class with Django default as abstract class.
from .models import User
# from django.contrib.auth.models import User
# Same goes for these forms.
from django.contrib.auth.forms import UserCreationForm, UserChangeForm
class ProfileChangeForm(UserChangeForm):
class Meta(UserCreationForm)
model = User
fields = ['first_name', 'last_name', 'email',]
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
self.fields['email'].disabled = True
As one can see, the needed user fields are specified. These are the fields that must be shown on the profile page. If other fields need to be added one has to specify them in the User class and add the attribute name to the fields list of the Meta class of this form.
After getting the required metadata the __init__ method is called initializing the form. However, within this method, the email field parameter 'disabled' is set to True. By doing so the behavior of the field in the front-end is altered resulting in a read-only field that one cannot edit even if one changes the HTML code. Reference Field.disabled
For completion, in the example below one can see the class-based views needed to use the form.
# view class in views.py
from django.contrib import messages
from django.contrib.messages.views import SuccessMessageMixin
from django.contrib.auth.mixins import LoginRequiredMixin
from django.views.generic import TemplateView, UpdateView
from django.utils.translation import gettext_lazy as _
class ProfileView(LoginRequiredMixin, TemplateView):
template_name = 'app_name/profile.html'
model = User
def get_context_data(self, **kwargs):
context = super().get_context_data(**kwargs)
context.update({'user': self.request.user, })
return context
class UserUpdateView(LoginRequiredMixin, SuccessMessageMixin, UpdateView):
template_name = 'app_name/update_profile.html'
model = User
form_class = ProfileChangeForm
success_message = _("Successfully updated your personal information")
def get_success_url(self):
# Please note, one has to specify a get_absolute_url() in the User class
# In my case I return: reverse("app_name:profile")
return self.request.user.get_absolute_url()
def get_object(self, **kwargs):
return self.request.user
def form_valid(self, form):
messages.add_message(self.request, messages.INFO, _("Successfully updated your profile"))
return super().form_valid(form)
The ProfileView class only shows an HTML page with some information about the user. Furthermore, it holds a button that if pressed leads to an HTML page configured by the UserUpdateView, namely 'app_name/update_profile.html'. As one can see, the UserUpdateView holds two extra attributes, namely 'form_class' and 'success_message'.
The view knows that every field on the page must be filled with data from the User model. However, by introducing the 'form_class' attribute the view does not get the default layout of the User fields. Instead, it is redirected to retrieve the fields through the form class. This has a huge advantage in the sense of flexibility.
By using form classes it is possible to show different fields with different restrictions for different users. If one sets the restrictions within the model itself every user would get the same treatment.
The template itself is not that spectacular but can be seen below.
# HTML template in 'templates/app_name/update_profile.html'
{% extends "base.html" %}
{% load static %}
{% load crispy_form_tags %}
{% block content %}
<h1>
Update your personal information
<h1/>
<div>
<form class="form-horizontal" method="post" action="{% url 'app_name:update' %}">
{% csrf_token %}
{{ form|crispy }}
<div class="btn-group">
<button type="submit" class="btn btn-primary">
Update
</button>
</div>
</div>
{% endblock %}
As can be seen, the form tag holds an action attribute that holds the view URL routing.
After pressing the Update button the UserUpdateView gets activated and it validates if all conditions are met. If so, the form_valid method is triggered and adds a success message. After successfully updating the data the user is returned to the specified URL in the get_success_url method.
Below one can find the code allowing the URL routing for the views.
# URL routing for views in urls.py
from django.urls import path
from . import views
app_name = 'app_name'
urlpatterns = [
path('profile/', view=views.ProfileView.as_view(), name='profile'),
path('update/', view=views.UserUpdateView.as_view(), name='update'),
]
There you have it. A fully worked out implementation of class-based views using form so one can alter an email field to be read-only and disabled.
My apologies for the extremely detailed example. There might be more efficient ways to design the class-based views, but this should work. Of course, I might have been wrong about some things said. I'm still learning as well. If anyone has any comments or improvements let me know!
