Welcome back, everyone, to this lecture, we're going to give you an overview of some of the jingo
theory behind connecting a view and a URL before we actually start cutting it out in the next lecture.
So as a refresher in jingo views essentially dictate what information is being shown to the client,
you URLs dictate where that information is shown on the actual website.
And these work in concert, so you can essentially think of each of you and you are appearing as a specific
web page on the website.
So very simply, you can just think of a view as a particular web page on your overall website.
But keep in mind, the view can't do it alone.
It needs to be routed through a URL.
You should also keep in mind that not every permutation of a Web page can be known in advance.
For example, how many total blog posts will a website blog eventually have?
You couldn't really know that ahead of time.
So luckily, jingo views and URLs actually support a lot of dynamic and logic features to help with
this sort of task.
For example, instead of having to hard code in an extension on your domain like blog, one block to
block three and so on.
You could have it be dynamic, so it should be blog RN.
And then every time a new template gets added, then you're going to automatically be able to route
that user to the correct blog post.
And it can be dynamic in the sense that if a blog post hasn't been created yet, you send them to a
404 page.
So we'll be learning about that later on.
Now, recall that we have essentially two main URLs that PY files and one is a URL configuration at
a project level, and then the other one is going to be at the app level.
And keep in mind, you can have multiple apps with multiple URLs that pays for each app.
Well, we end up doing is we connect that view through the URL in the app level all the way to the URL
and the project level through the use of path and include Django functions and a list of the view routes
is defined in a list variable called URL patterns, which we've already seen a little bit of.
So recall, previously we ended the last section by creating a view, connecting it to a URL route within
the application and then connecting that URL to the project level URLs that file.
And we're really going to focus on this particular dynamic for the rest of this section, and we'll
get into more and more complex.
These functionalities feature sets for what you can actually do with these URL routes and their particular
views.
Now, when we actually connect a view to our U you l, we do it with a path function call, and the
first argument that's required any path function call is the actual route.
That's going to be the string code that contains the URL pattern.
And what ends up happening is Django actually scans the relevant URL patterns list until it finds a
matching string route, for example, app forward slash.
And keep in mind, later on, we'll see.
We can actually make these sort of routes dynamic to take in an integer that we don't actually know
ahead of time.
Then we have the second required argument underneath the path function, which is the actual view.
So once the matching route is found, the view argument connects to a function or view.
Typically, the find the views that profile the relevant Django app.
So these are the two main arguments you need to be concerned with whenever you're defining path inside
some URLs that pie file, it's where is the actual route to show either a template or your URL on the
website.
And then what view should I be showing it?
So where is the information going to be shown and then what is the information that's going to be shown?
The other two optional arguments are keyword arguments.
So we'll see that later on, we can actually pass in keyword arguments as a dictionary to the view and
have a lot more flexibility.
And then the fourth optional argument is name and actually allows us to name a URL in order to reference
it elsewhere in Django.
We're going to see when we start introducing templates.
This is a very powerful feature that allows us to simply reference a view and URL route through the
use of a custom defined name.
So coming up next, we're to create some simple views in our app and connect them to our project, your
roots.
Let's go ahead and do that in the next lecture.