Django Views — The Right Way

While Django Mixins (like LoginRequiredMixin) can be used in Class-Based Views (CBVs) by adding them to the inheritance list, they do not always compose reliably.

The Risk: If multiple mixins rely on the same method (e.g., overriding dispatch()) and do not use super() correctly, or if they use specific implementations like Django's UserPassesTestMixin (which cannot be stacked), they may silently fail. In such cases, only one of the checks might actually run, potentially creating security vulnerabilities.

Best Practice:

• If you need multiple preconditions in a CBV, consider building a single mixin that combines the logic, or use decorators on the view methods if possible.
• Decorators are generally safer for composition because they wrap existing functionality via an interface, whereas mixins inject logic into the middle of a class hierarchy and depend heavily on implementation details.

Depending on the scope and cost of the data, choose one of the following Django patterns:

1. Site-wide data: Use Django context processors if the data is needed on almost every page.
2. Expensive site-wide data: Use lazy evaluation within your context processor to avoid unnecessary computation.
3. Template-level components: Use custom inclusion template tags for data needed by specific UI components (like headers or footers) that appear in multiple templates. This allows the component to load its own data without modifying view functions.
4. Group-specific data: Use helper functions (as described in the composition guide) for data shared by a specific subset of views (e.g., all checkout pages).

To avoid the 'bare view' problem of django-decorator-include, you can use a two-step pattern:

1. The Policy Decorator: A decorator that performs the actual logic (e.g., checking if a user is premium) and sets a specific attribute on the view function to signal that the policy has been applied.
2. The Checking Decorator: A decorator used within django-decorator-include that does nothing at runtime but checks at import time if the required attribute is present on the view. If the attribute is missing, it raises an AssertionError.

This ensures that if you forget to decorate a view, the application fails to start, preventing security holes from reaching production.

Implementation Example:

_SECURITY_POLICY_APPLIED = "_SECURITY_POLICY_APPLIED"

# 1. The Checker
def check_security_policy_applied(view_func):
    if not getattr(view_func, _SECURITY_POLICY_APPLIED, False):
        raise AssertionError(f"{view_func.__module__}.{view_func.__name__} needs to have a security policy applied")
    return view_func

# 2. The Policy
def premium_required(view_func):
    @functools.wraps(view_func)
    def wrapper(request, *args, **kwargs):
        if not (request.user.is_authenticated and request.user.is_premium):
            # ... handle unauthorized access ...
            return HttpResponseRedirect('/')
        return view_func(request, *args, **kwargs)

    setattr(wrapper, _SECURITY_POLICY_APPLIED, True)
    return wrapper

# 3. Usage in urls.py
urlpatterns = [
    include('myapp.urls', decorators=[check_security_policy_applied]),
]

Complex Class-Based View (CBV) hierarchies involving multiple mixins can lead to Method Resolution Order (MRO) issues, sometimes requiring custom metaclasses (like AjaxMroFixer) to reorder how methods like post are inherited.

To avoid the need for 'metaclass fixes' and to make code easier to maintain, consider refactoring complex CBVs into Function-Based Views (FBVs). An FBV can explicitly handle form flow control, request methods, and template responses without delegating to a deep chain of base classes.

@booking_account_required
@ajax_form_validate(AccountDetailsForm)
def account_details(request):
    form_class = AccountDetailsForm

    if request.method == "POST":
        form = form_class(request.POST, instance=request.booking_account)
        if form.is_valid():
            form.save()
            messages.info(request, 'Account details updated, thank you.')
            return next_step(request.booking_account)
    else:
        form = form_class(instance=request.booking_account)

    return TemplateResponse(request, 'cciw/bookings/account_details.html', {
        'title': 'Booking - account details',
        'stage': BookingStage.ACCOUNT,
        'form': form,
    })

The project advocates for Function-Based Views (FBVs) over Class-Based Views (CBVs) like TemplateView or ListView to maintain visibility of the core Django request-response cycle.

FBV Example:

def my_view(request):
    return TemplateResponse(request, 'template.html', {'data': 'value'})

CBV Example (Obscured):

from django.views.generic import TemplateView

class ExampleView(TemplateView):
    template_name = "example.html"

To avoid keyword argument clashes in urls.py when using extra options, use a "view factory". A view factory is a function that accepts configuration parameters and returns a specific view function. This pattern is useful for creating many similar views that only differ by configuration.

Benefits:

• Prevents clashes between urls.py kwargs and the view's own arguments.
• Allows the inner view function to have a specific, type-checked signature.

from django.urls import reverse
from django.http import HttpResponseRedirect

def make_redirector(pattern_name=None, permanent=False, query_string=False):
    def redirector(request, *args, **kwargs):
        url = reverse(pattern_name, args=args, kwargs=kwargs)
        # Implementation of permanent/query_string logic goes here
        return HttpResponseRedirect(url)
    return redirector

# Usage in urls.py
urlpatterns = [
    path('old-path/<int:pk>/', make_redirector(
        pattern_name='my_view',
        permanent=True,
        query_string=True,
    )),
]