django

eli5 Django

Marcelino Veloso III,

Imagine the request-response pattern.

A client, usually a browser, makes a request to an http server. The server responds with data from a database, templated with html, css and js.

The request

  1. When runserver starts and we click on http://127.0.0.1:8000/, the browser initiates an HttpRequest to the server.
  2. Django matches the endpoint of this url to a developer-defined UrlPattern route.
  3. What is the endpoint? Well, it's the tip of the url. In the url above, it would be /: this is the tip, the endpoint.
  4. The router's matching process goes something like this for url http://127.0.0.1:8000/:
    1. Does endpoint of http://127.0.0.1:8000/ match /about? No.
    2. Does endpoint of http://127.0.0.1:8000/ match /contact-us? No.
    3. Does endpoint of http://127.0.0.1:8000/ match /? Yes

The response

  1. The endpoint / is typically the homepage of the website.
  2. It's up to the developer to construct how this View looks like, typically by combining html, css, and js with data.
  3. So the UrlRoute represents a pre-constructed homepage View
  4. This View, based on http://127.0.0.1:8000/, will then be rendered as a HttpResponse for the browser.

Summary

We started with a requesting url and retrieved a viewable response.

  1. The url's endpoint made an HttpRequest to the server.
  2. The server looked for UrlPatterns, replying with: "Yes, I have a View representing request to /"
  3. This View is packaged into an HttpResponse for rendering in the browser.
  4. Since the View will likely contain other urls... we can expect more request-response cycles.

This is a naive understanding of the flow but should cover how clicks become views.

For a more comprehensive approach, the constantly updated books of Will Vincent are likely your best bet in understanding Django better. He uses class-based views for his examples so this might be appreciated further by diving into the more functional approach used by Django Girls.