This chapter is from the book
This chapter is from the book
This chapter is from the book
1.5 Django: Python Web Framework
As outlined in Section 1.3, a website must always
- Receive an HTTP request (the user asks for a webpage)
- Process the request
- Return the requested information as an HTTP response (the user sees the webpage)
Django is a free and open-source Python back-end web framework that removes the tedium of building websites by providing most of the required behavior. Django handles the majority of the HTTP request and response cycle (the rest is handled by the server Django runs on top of). Developers need only focus on processing the HTTP request, and Django provides tools to make even that easy.
All Django projects are organized in the same way, largely because of the framework’s inversion of control but also because it makes navigating existing Django projects much easier for developers who, for instance, maintain the code or step into a job mid-project.
Django’s project structure is most often described according to the Model-View-Controller (MVC) architecture because it makes the framework easier to learn. Originally, MVC was a very specific architecture, but it has become an umbrella term for libraries that are patterned after the following idea (illustrated in Figure 1.4):
){kind=link}
- The Model controls the organization and storage of data and may also define data-specific behavior.
- The View controls how data is displayed and generates the output to be presented to the user.
- The Controller is the glue (or middleman) between the Model and View (and the User); the Controller will always determine what the user wants and return data to the user, but it may also optionally select the data to display from the Model or use the View to format the data.
Figure 1.4: MVC Architecture Diagram
Most often, literature will state that different pieces of Django map to different pieces of MVC. Specifically,
- Django models are an implementation of MVC Models (Chapter 3: Programming Django Models and Creating a SQLite Database).
- Django templates map to MVC Views (Chapter 4: Rapidly Producing Flexible HTML with Django Templates).
- Django views and URL configuration are the two pieces that act as the MVC Controller (Chapter 5: Creating Webpages with Controllers in Django).
The truth is a little bit more complicated. Django projects aren’t truly MVC, especially if we abide by the original definition. We will discuss this topic in much more depth in Chapter 12: The Big Picture, once we have a better grasp of all of the moving pieces. For the moment, because it can help beginners organize the framework, we continue to use the (more modern and vague version of) MVC architecture to make sense of the framework.
If we combine our diagrams of the HTTP request/response loop and MVC architecture as in Figure 1.5, we get a much better picture of how Django works.
)
Figure 1.5: Application of MVC Architecture Diagram
The Controller, the subject of Chapter 5, represents the heart of Django and is the only part of the MVC architecture that is necessary to generate a webpage. However, most browsers expect data to be returned by the server in specific formats, such as XML, HTML, or HTML5. The View encapsulates the tools Django supplies for easily outputting such data and is the subject of Chapter 4. Finally, we typically need to use persistent data when generating content in the Controller. The Model section represents the tools for structuring and storing data and is the subject of Chapter 3.
You’ll note that the Model section is connected to a database. The Model itself does not store data but instead provides tools for communicating with databases. We discuss the merits of databases in more depth in Chapter 3. For the moment, just note that Django provides the tools to communicate with several different databases, including SQLite, MySQL, PostgreSQL, and Oracle, which is yet another huge time-saver for us.
Django provides many more tools to make building websites easy. For instance, database schema migrations (Chapter 3 and Chapter 10: Revisiting Migrations), which help with managing models, and an authentication system (Chapter 19 and Chapter 22: Overriding Django’s Authentication with a Custom User) are built in. What’s more, Django is Python code, allowing developers to use any standard or third-party Python library. Python libraries afford developers an enormous amount of power and flexibility.
Django prides itself on being the “web framework for perfectionists with deadlines.” Django provides the functionality needed for every website. The framework also comes with tools to make common website features easy to implement. This “batteries included” approach is why tens of thousands of developers use Django. Released into the wild in 2005, Django powers many websites, including Instagram, Pinterest, Disqus, and even The Onion. The core team of Django developers rigorously and regularly test Django, making it both fast and safe.
Django follows the Don’t Repeat Yourself (DRY) principle. You will never need to repeat your code if you don’t want to (of course, Django won’t stop you if you do). Additionally, Django adheres to the Python philosophy that explicit is better than implicit. Django will never assume what you want and will never hide anything from you. If there is a problem, Django will tell you.
As mentioned in Section 1.3, despite all of the things Django will do for you, it will not build or help build front-end behavior for you (this is the purview of JavaScript apps and the browser). Django is a back-end framework, only one half of the equation for building a modern website. It allows you to dynamically create HTML for the front end (Chapter 4) and to intelligently provide the content necessary for a modern front end (Chapter 16), but it does not provide the tools to build dynamic browser behavior for the user. However, before you toss this book in a corner and walk away from Django forever, note that a back end is necessary before a front end can exist. A back end may be only half of the equation, but it is the first half: without the request/response loop, there is no website.