Models, routing, views, and templates

- [Instructor] When working with any web framework, it's important to understand its underlying architecture, or conceptual structure. Broadly, Django uses an MVC, or Model-View-Controller architecture. However, Django uses some different names for these. The four pieces to understand are URL patterns, views, models, and templates. Each of these has a separate role. In this section, we'll discuss the relationship of each of these pieces with some examples. During the course, we'll look more closely at each one individually. When a Django application receives a web request, it uses the URL patterns to decide which view to pass the request to for handling. In our project, the URL patterns will be defined in wisdompets/urls.py. Views provide the logic or control flow portion of the project. A view is a Python callable, such as a function that takes an HTTP request as an argument and returns an HTTP response for the web server to return. Our views will be defined at adoptions/views.py. To perform queries against the database, each view can leverage Django models as needed. We will define our models for the adoptions app in adoptions/models.py. A Django model is a class with attributes that define the schema or underlying structure of a database table. These classes will provide built-in methods for making queries on the associated tables. Each view we define can also leverage templates, which help with the presentation layer of what the HTML response will look like. Each template is a separate file that consists of HTML along with some extra template syntax for variables, loops, and other control flow. Our template files will be placed in a folder that we'll create called templates, and it will be inside of the adoptions folder. Given this overall structure, let's walk through the control flow we'll create in our adoptions app. If a request comes into Django with a root path of just a slash, Django will first look at the URL patterns to find in urls.py to find what view it should use. The URL patterns will route to the function in views.py called home. This home function will take the request as an argument, and it will first make any database calls that are needed, using the models to find in models.py. For our homepage, we'll list the pets available for adoption, so this query will find the name of each pet and some associated information for each one. Next, the home view will pass the HTTP request and this data from the database into the template file home.html. At this point, the template will render HTML based on the data it is given, and the view will return an HTTP response with this HTML as the body, thus completing the processing for the request. Similarly, if a request comes in with the path /adoptions/1, the URL patterns will route the request to the pet_detail function in views.py. Unlike the home path, this URL contains a number that is treated as a variable, which is a one in this example. The URL pattern will parse this variable and pass it along to the pet_detail view with a keyword argument of pet_id. The pet_detail view will use the number that's passed in as an ID value for the pet that it will query for details. Lastly, this data for the pet is passed to the pet_detail.html template, which renders the associated HTML. As we begin building our project, we'll implement some pieces in isolation, but we'll sometimes need to stub out related parts until all of them are complete. Once we've completed each piece, this overall structure and the relationship between the parts will become more concrete. With this in mind, we're ready to implement the major components of our project.