Bird
Raised Fist0
Djangoframework~5 mins

Why views handle request logic in Django

Choose your learning style10 modes available
Introduction

Views in Django decide what happens when someone visits a web page. They take the request and choose what to show back.

When you want to show a web page based on user input.
When you need to get data from a database and display it.
When you want to handle form submissions from users.
When you need to check if a user is logged in before showing content.
When you want to send different responses depending on the request type.
Syntax
Django
from django.http import HttpResponse

def view_name(request):
    # process request data
    # prepare response
    return HttpResponse('response content')
The request parameter holds all information about the user's visit.
Views always return a response, like a web page or a redirect.
Examples
A simple view that returns a plain text greeting.
Django
from django.http import HttpResponse

def hello(request):
    return HttpResponse('Hello, world!')
This view sends data to a template to create a web page.
Django
from django.shortcuts import render

def home(request):
    context = {'name': 'Alice'}
    return render(request, 'home.html', context)
Handles form submission and redirects after success.
Django
from django.http import HttpResponseRedirect

def submit_form(request):
    if request.method == 'POST':
        # process form data
        return HttpResponseRedirect('/thanks/')
    return HttpResponse('Please submit the form.')
Sample Program

This view reads a 'user' name from the URL query and greets them. If no name is given, it says 'Guest'.

Django
from django.http import HttpResponse

def greet_user(request):
    user = request.GET.get('user', 'Guest')
    return HttpResponse(f'Hello, {user}! Welcome to our site.')
OutputSuccess
Important Notes

Views are the place to decide what the user sees or what happens next.

Keep views simple: they should handle requests and responses, not complex logic.

Use Django's built-in helpers like render to make views cleaner.

Summary

Views handle the logic of what to do when a user visits a page.

They take the request, process data, and return a response.

This keeps your web app organized and easy to understand.

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

  1. 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.
  2. Step 2: Understand the role of templates

    Templates only display the data and do not contain logic to process requests.
  3. Final Answer:

    Because views process data and decide what response to send -> Option B
  4. Quick Check:

    Views handle logic [OK]
Hint: Remember: views handle logic, templates handle display [OK]
Common Mistakes:
  • Thinking templates handle data processing
  • Confusing views with database models
  • Believing templates manage user authentication
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

  1. Step 1: Check function parameters

    A Django view must accept at least one parameter named 'request' representing the user's request.
  2. Step 2: Check return type

    The view should return an HttpResponse object or similar, not just print or return a string.
  3. Final Answer:

    def my_view(request): return HttpResponse('Hello') -> Option D
  4. 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

  1. 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'.
  2. Step 2: Check the URL query parameter

    The URL has '?name=Anna', so 'name' is 'Anna', not missing.
  3. Final Answer:

    Hello, Anna! -> Option A
  4. 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

  1. Step 1: Understand request.POST usage

    request.POST contains data only for POST requests; a GET request has no POST data.
  2. Step 2: Accessing missing key causes error

    Accessing request.POST['username'] when missing raises KeyError.
  3. Final Answer:

    KeyError because 'username' is missing in POST data -> Option A
  4. 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

  1. Step 1: Check how to detect request method

    Use request.method to check if the request is 'POST' or 'GET'.
  2. 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).
  3. Final Answer:

    def my_view(request): if request.method == 'POST': return HttpResponse('Posted') else: return HttpResponse('Got') -> Option C
  4. 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 unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard