- 1.1 Introduction
- 1.2 Website Basics
- 1.3 Understanding Modern Websites
- 1.4 Building Modern Websites: The Problems That Frameworks Solve and Their Caveats
- 1.5 Django: Python Web Framework
- 1.6 Defining the Project in Part I
- 1.7 Creating a New Django Project and Django Apps
- 1.8 Putting It All Together
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.4 Building Modern Websites: The Problems That Frameworks Solve and Their Caveats
Very few people program dynamic websites from scratch anymore (i.e., without relying on other people’s code). It is a difficult, tedious process, and it is typically not a good use of time. Instead, most developers rely on frameworks.
A framework is a large codebase, or collection of code, meant to provide universal, reusable behavior for a targeted project. For example, a mobile framework, such as those provided by Apple and Google for their mobile phones or smartphones, provides key functionality for building mobile apps. Consider the many touch actions on the iPhone: a user can tap his or her screen or hold, slide, turn with two fingers, and more. Developers do not need to worry about figuring out what touch action the user has performed: Apple’s framework handles that task for developers.
Using frameworks offers enormous advantages. The most obvious is the removal of tedious and repetitive tasks: if iPhone apps require specific behavior, then the framework will provide it. This saves time for developers not only because of the provided functionality, which allows developers to avoid coding entirely, but also because the code provided is tested by many other developers on a wide variety of projects. This widespread testing is particularly important when it comes to security—a group of developers working on a framework are more likely to get sensitive components right than is any single developer.
Frameworks are different from other external codebases, such as libraries, because they feature inversion of control. Understanding inversion of control is key to properly using frameworks. Without a framework, the developer controls the flow of a program: he or she creates behavior or pulls behavior into the code project by calling functions from a library or toolkit. By contrast, when using a framework, the developer adds or extends code in specific locations to customize the framework to the program’s requirements. The framework, which is essentially the base of the program, then calls those functions implemented by the developer. In this way, the framework, not the developer, dictates control flow. This is sometimes referred to as the Hollywood principle: “Don’t call us, we’ll call you.” We can easily demonstrate the difference in pseudocode (Example 1.1).
Example 1.1: Python Code
# Using a Library
def my_function(*args):
...
library.library_function(*args)
...
# Using a framework
def my_function(*args):
...
framework.run(my_function)Inversion of control may seem counterintuitive or even impossible. How may the robot choose its behavior? Remember: the framework is built by other developers, and they are the ones who specify the behavior followed by the framework. As a developer using a framework, you are simply adding to or directing the behavior provided by other developers.
Using a framework has a few caveats. A framework may offer significant time savings, reusability, and security and may encourage a more maintainable and accessible codebase, but only if the developer is knowledgeable about the framework. A developer cannot fill in all the gaps (by adding or extending code) expected by the framework until he or she understands where all the gaps are. Learning a framework can be tricky: because a framework is an interdependent system, using a part of the framework may require understanding another part of the system (we’ll see this in Chapter 6: Integrating Models, Templates, Views and URL Configurations to Create Links between Webpages), which requires knowledge and tools from the three chapters preceding it. For this reason, using a framework requires investing significant overhead in learning the framework. In fact, it will take all of Part I of this book to explain the core inner workings of Django and to gain a holistic understanding of the framework. But once there, we’ll be off to the races.
Despite this overhead, it is in your interest to use a framework and to spend the time to learn how to use it properly. Colloquially, developers are told, “Don’t fight the framework.”