A view in Django handles the logic for processing a web request and returning a response. It acts like a middleman between the user and the data.
Click to reveal answer
beginner
Why does Django put request logic inside views instead of models or templates?
Views keep request logic separate to keep models focused on data and templates focused on display. This separation makes the code easier to manage and understand.
Click to reveal answer
beginner
How do views help in controlling what the user sees?
Views decide what data to get and which template to use, so they control what the user sees based on the request they made.
Click to reveal answer
beginner
What happens inside a Django view when a user sends a request?
The view checks the request, gets or changes data if needed, and then sends back a response like a webpage or data.
Click to reveal answer
beginner
How does handling request logic in views improve code organization?
It keeps the code clean by separating data (models), logic (views), and display (templates), making it easier to update and fix.
Click to reveal answer
What is the primary responsibility of a Django view?
AHandling request logic and returning a response
BStoring data in the database
CDesigning the webpage layout
DManaging user authentication
✗ Incorrect
Views handle the logic for processing requests and returning responses.
Why should request logic not be placed in Django templates?
ATemplates are only for styling
BTemplates cannot access the database
CTemplates run too slowly
DTemplates are only for displaying data
✗ Incorrect
Templates focus on display, not on processing logic.
Which part of Django is responsible for data storage and retrieval?
AForms
BViews
CModels
DTemplates
✗ Incorrect
Models handle data storage and retrieval.
What does a Django view typically return after processing a request?
AAn HTTP response
BA database record
CA CSS file
DA JavaScript function
✗ Incorrect
Views return HTTP responses like webpages or JSON data.
Separating request logic into views helps to:
AReduce the size of the database
BKeep code organized and easier to maintain
CMake the website load faster
DAutomatically generate templates
✗ Incorrect
Separation of concerns keeps code clean and maintainable.
Explain why Django views handle request logic instead of models or templates.
Think about what each part of Django is responsible for.
You got /4 concepts.
Describe the flow of a web request through a Django view.
Imagine how a waiter takes your order and brings your food.
You got /4 concepts.
Practice
(1/5)
1. Why do Django views handle request logic instead of templates?
easy
A. Because templates are only for styling the page
B. Because views process data and decide what response to send
C. Because views store the database records
D. Because templates handle user authentication
Solution
Step 1: Understand the role of views
Views receive the user's request and decide what to do with it, like fetching data or processing input.
Step 2: Understand the role of templates
Templates only display the data and do not contain logic to process requests.
Final Answer:
Because views process data and decide what response to send -> Option B
2. Which of the following is the correct way to define a Django view function that handles a request?
easy
A. def my_view(request, response): return 'Hello'
B. def my_view(): return HttpResponse('Hello')
C. def my_view(request): print('Hello')
D. def my_view(request): return HttpResponse('Hello')
Solution
Step 1: Check function parameters
A Django view must accept at least one parameter named 'request' representing the user's request.
Step 2: Check return type
The view should return an HttpResponse object or similar, not just print or return a string.
Final Answer:
def my_view(request): return HttpResponse('Hello') -> Option D
Quick Check:
View(request) returns HttpResponse [OK]
Hint: View functions always take 'request' and return HttpResponse [OK]
Common Mistakes:
Omitting the request parameter
Returning plain strings instead of HttpResponse
Adding extra parameters not handled by Django
3. Given this view code:
from django.http import HttpResponse
def greet(request):
name = request.GET.get('name', 'Guest')
return HttpResponse(f'Hello, {name}!')
What will be the response if the user visits /greet?name=Anna?
medium
A. Hello, Anna!
B. Hello, Guest!
C. Hello, None!
D. Error: name parameter missing
Solution
Step 1: Understand request.GET.get usage
The code tries to get the 'name' parameter from the URL query string; if missing, it uses 'Guest'.
Step 2: Check the URL query parameter
The URL has '?name=Anna', so 'name' is 'Anna', not missing.
Final Answer:
Hello, Anna! -> Option A
Quick Check:
Query param 'name' = Anna [OK]
Hint: Check URL query parameters and default values [OK]
Common Mistakes:
Assuming default is always used
Confusing GET with POST data
Expecting an error if parameter is missing
4. This view code has an error:
def show(request):
user = request.POST['username']
return HttpResponse(f'User: {user}')
What is the likely error when a GET request is made to this view?
medium
A. KeyError because 'username' is missing in POST data
B. SyntaxError due to missing colon
C. TypeError because request.POST is not a dictionary
D. No error, returns empty user
Solution
Step 1: Understand request.POST usage
request.POST contains data only for POST requests; a GET request has no POST data.
Step 2: Accessing missing key causes error
Accessing request.POST['username'] when missing raises KeyError.
Final Answer:
KeyError because 'username' is missing in POST data -> Option A
Quick Check:
Missing POST key causes KeyError [OK]
Hint: Access POST keys safely or check request method first [OK]
Common Mistakes:
Assuming POST data exists on GET requests
Expecting empty string instead of error
Confusing KeyError with SyntaxError
5. You want a view to handle both GET and POST requests differently. Which code correctly handles this logic?
hard
A. def my_view(request):
if request.GET:
return HttpResponse('Posted')
else:
return HttpResponse('Got')
B. def my_view(request):
if request.POST:
return HttpResponse('Posted')
else:
return HttpResponse('Got')
C. def my_view(request):
if request.method == 'POST':
return HttpResponse('Posted')
else:
return HttpResponse('Got')
D. def my_view(request):
if request.method == 'GET':
return HttpResponse('Posted')
else:
return HttpResponse('Got')
Solution
Step 1: Check how to detect request method
Use request.method to check if the request is 'POST' or 'GET'.
Step 2: Verify correct branching
def my_view(request):
if request.method == 'POST':
return HttpResponse('Posted')
else:
return HttpResponse('Got') correctly returns 'Posted' for POST and 'Got' for others (like GET).
Final Answer:
def my_view(request):
if request.method == 'POST':
return HttpResponse('Posted')
else:
return HttpResponse('Got') -> Option C
Quick Check:
Use request.method to branch logic [OK]
Hint: Check request.method string, not request.POST or GET dict [OK]
Common Mistakes:
Checking if request.POST or request.GET is truthy instead of method
Mixing up GET and POST conditions
Returning wrong response for request types
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.