Handling DELETE Requests in Django 4.x DeleteView

You've identified an important issue when migrating from Django 3.2 to 4.2 regarding the DeleteView changes. In Django 4.0, DeleteView now uses FormMixin to handle POST requests, which means custom deletion logic should be moved from delete() to form_valid().

The Problem

Your issue occurs because:

1. Your validation logic in form_valid() works for POST requests
2. When using client.delete() in tests or when clients use the DELETE HTTP verb, DeletionMixin.delete() is called directly
3. This bypasses your validation logic in form_valid()

Solutions

Here are some approaches to solve this issue:

1. Override dispatch() Method

The most straightforward solution is to override the dispatch() method to handle DELETE requests by converting them to POST requests internally:

PYTHONCopied
class CustomDeleteView(DeleteView):
    def dispatch(self, request, *args, **kwargs):
        # Convert DELETE requests to POST internally
        if request.method == 'DELETE':
            request.method = 'POST'
        return super().dispatch(request, *args, **kwargs)

This approach ensures that DELETE requests go through the same validation path as POST requests.

2. Create a Shared Helper Method

Another approach is to create a shared helper method that contains your validation logic, then call it from both form_valid() and delete():

PYTHONCopied
class CustomDeleteView(DeleteView):
    def validate_and_prepare_deletion(self, obj):
        # Your validation logic here
        # Raise ValidationError if validation fails
        # Return any data needed for deletion
        return True
        
    def form_valid(self, form):
        self.object = self.get_object()
        self.validate_and_prepare_deletion(self.object)
        return super().form_valid(form)
        
    def delete(self, request, *args, **kwargs):
        self.object = self.get_object()
        self.validate_and_prepare_deletion(self.object)
        return super().delete(request, *args, **kwargs)

Note that overriding delete() might trigger Django's warning, but this approach should work if implemented carefully.

3. Custom Middleware

You could create middleware that converts DELETE requests to POST requests for specific URL patterns:

PYTHONCopied
class ConvertDeleteToPostMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        # Check if this is a DELETE request to a view that should use POST
        if request.method == 'DELETE' and self.should_convert_to_post(request.path):
            request.method = 'POST'
        return self.get_response(request)
    
    def should_convert_to_post(self, path):
        # Logic to determine if this path should have DELETE converted to POST
        # For example, check if it matches patterns for your DeleteViews
        return True  # Implement your logic here

Recommendation

The first approach (overriding dispatch()) is likely the cleanest solution as it:

1. Doesn't require changing your test suite
2. Handles external clients using DELETE requests
3. Avoids the warnings from Django about overriding delete()
4. Ensures all requests go through the same validation path

This approach aligns with Django's design philosophy of having a single path for handling a particular action, which makes your code more maintainable and less prone to bugs.