Jump into concepts and practice - no test required
or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
DeleteView for removal
📖 Scenario: You are building a simple Django app to manage a list of books. You want to allow users to delete a book from the list using Django's built-in DeleteView.
🎯 Goal: Create a Django DeleteView to remove a book from the database. The view should use the correct model, template, and redirect URL after deletion.
📋 What You'll Learn
Create a Django model called Book with fields title and author.
Create a DeleteView class called BookDeleteView that deletes a Book instance.
Set the model attribute of BookDeleteView to Book.
Set the template_name attribute of BookDeleteView to book_confirm_delete.html.
Set the success_url attribute of BookDeleteView to reverse_lazy('book-list').
💡 Why This Matters
🌍 Real World
Deleting records is a common feature in web apps, such as removing posts, products, or user data.
💼 Career
Understanding Django's class-based views like DeleteView is essential for building maintainable and efficient web applications.
Progress0 / 4 steps
1
Create the Book model
Create a Django model called Book with two fields: title as a CharField with max length 100, and author as a CharField with max length 100.
Django
Hint
Use models.CharField(max_length=100) for both fields inside the Book class.
2
Import DeleteView and reverse_lazy
Import DeleteView from django.views.generic and reverse_lazy from django.urls.
Django
Hint
Use from django.views.generic import DeleteView and from django.urls import reverse_lazy.
3
Create the BookDeleteView class
Create a class called BookDeleteView that inherits from DeleteView. Set its model attribute to Book, template_name to 'book_confirm_delete.html', and success_url to reverse_lazy('book-list').
Django
Hint
Define BookDeleteView as a subclass of DeleteView and set the three attributes exactly as specified.
4
Add URL pattern for BookDeleteView
Add a URL pattern to urls.py that maps the path 'book/delete/<int:pk>/' to BookDeleteView.as_view() with the name 'book-delete'.
Django
Hint
Use path('book/delete//', BookDeleteView.as_view(), name='book-delete') inside urlpatterns.
Practice
(1/5)
1. What is the main purpose of Django's DeleteView?
easy
A. To list all objects of a model
B. To create a new object in the database
C. To display a confirmation page and delete an object upon confirmation
D. To update an existing object in the database
Solution
Step 1: Understand DeleteView functionality
DeleteView is designed to handle deletion of objects with a confirmation step.
Step 2: Compare with other views
Creating, updating, and listing objects are handled by other views like CreateView, UpdateView, and ListView.
Final Answer:
To display a confirmation page and delete an object upon confirmation -> Option C
Quick Check:
DeleteView = confirmation + delete [OK]
Hint: DeleteView always confirms before deleting [OK]
Common Mistakes:
Confusing DeleteView with CreateView or UpdateView
Thinking DeleteView deletes without confirmation
Assuming DeleteView lists objects
2. Which of the following is the correct way to specify the URL to redirect after a successful delete in a DeleteView?
easy
A. redirect_url = reverse('home')
B. success_redirect = 'home/'
C. url_redirect = 'home/'
D. success_url = reverse_lazy('home')
Solution
Step 1: Identify correct attribute for redirect
DeleteView uses success_url to define where to go after deletion.
Step 2: Use reverse_lazy for URL resolution
Since URLs are resolved lazily in class-based views, reverse_lazy is preferred over reverse.
Hint: Use success_url with reverse_lazy for redirects [OK]
Common Mistakes:
Using reverse instead of reverse_lazy in class attributes
Using wrong attribute names like redirect_url
Assigning plain strings without URL reversing
3. Given this DeleteView code snippet, what happens when the user confirms deletion?
class BookDeleteView(DeleteView):
model = Book
template_name = 'books/book_confirm_delete.html'
success_url = reverse_lazy('book-list')
medium
A. The book is deleted and user is redirected to the book list page
B. The book is updated and user stays on the same page
C. The book is deleted but user stays on the confirmation page
D. Nothing happens because success_url is incorrect
Solution
Step 1: Confirm DeleteView behavior on confirmation
When the user confirms, the object specified by model is deleted.
Step 2: Check success_url usage
After deletion, the user is redirected to the URL given by success_url, here 'book-list'.
Final Answer:
The book is deleted and user is redirected to the book list page -> Option A
Quick Check:
Delete + redirect = The book is deleted and user is redirected to the book list page [OK]
Hint: Confirm deletes object and redirects to success_url [OK]
Common Mistakes:
Thinking the object is updated instead of deleted
Assuming user stays on confirmation page after delete
Believing success_url must be a string, not reverse_lazy
4. Identify the error in this DeleteView subclass:
class ArticleDeleteView(DeleteView):
model = Article
template_name = 'articles/delete.html'
success_url = reverse('article-list')
medium
A. template_name should be 'article_confirm_delete.html'
B. Using reverse() instead of reverse_lazy() for success_url
C. Missing the get_object() method override
D. model attribute should be a string, not a class
Solution
Step 1: Check success_url assignment in class attribute
Class attributes are evaluated at import time, so reverse() causes errors here.
Step 2: Use reverse_lazy() for lazy URL resolution
reverse_lazy() delays evaluation until runtime, fixing the error.
Final Answer:
Using reverse() instead of reverse_lazy() for success_url -> Option B
Quick Check:
reverse_lazy needed for class attributes [OK]
Hint: Use reverse_lazy in class attributes, not reverse [OK]
Common Mistakes:
Overriding get_object() unnecessarily
Assuming template_name must follow a strict name
Using model as string instead of class (both work but class preferred)
5. You want to customize the confirmation page of a DeleteView to show extra context data like the current user's name. Which method should you override to add this data?
hard
A. get_context_data()
B. get_object()
C. form_valid()
D. dispatch()
Solution
Step 1: Understand where to add extra template data
Extra data for templates is added by overriding get_context_data().
Step 2: Confirm other methods' purposes
get_object() fetches the object, form_valid() handles form submission, and dispatch() manages request flow.
Final Answer:
get_context_data() -> Option A
Quick Check:
Extra template data = get_context_data() [OK]
Hint: Add extra template info by overriding get_context_data() [OK]