Variable Arguments From URLs: Routing and Views
In the previous lesson, you learned how to pull one specific resource out of your database. Now you need to build that code into your views and set up the correct routing so that you’ll be able to see the details page of one of your projects.
urlpatterns in your
projects app, you had an empty path that just went to
projects without anything afterwards and then rendered your
all_projects view. Now, you need to add a second path:
urlpatterns = [ path('', views.all_projects), path('<int:pk>', views.project_detail) ]
You can use the characters
> to captures a part of a URL and pass it forward into your app.
00:00 In the previous video, we learned how to pull one specific resource out of our database. Now, we want to build that code into our views and set up the correct routing so that we’re able to see this details view of one of our projects.
Over here in the
urlpatterns of our
projects app—remember, we have this empty path that just goes to
/projects/ without anything afterwards—and then renders our
all_projects() view, which lists all the projects that we have.
All right. So, PyCharm’s complaining,
project_detail—this view doesn’t exist yet. We already know what that’s going to bring us, it’s going to bring us a little error, but we can build this view.
So, that looks weird, right? We don’t have just some text in there, but we have these angled brackets. We have a
: in there.
int looks familiar, could be integer, right?
pk—we just talked about that before.
01:25 Maybe it’s the primary key. But what exactly is going on in here? Let’s take a look at this on some slides! So, what we want to do with these angled brackets is we want to use them to capture parts of the URL.
So, what you can see here is essentially what—in the demo, before—I typed into the browser bar up top, right? We were on
/projects/, and then we could just type the different numbers—in this case,
1—and then it brought us to this details page.
What’s happening here is that our cowboy emoji lassos the rest of the URL—the number, in this case—with the angled brackets, and then flips it up there and passes it on to our view, whatever we defined here—in this case,
But this is going to be available inside of
project_detail()—in this view function—under the variable
pk, okay? That’s important to remember for us to then build out the view that we need to correctly render this details page. All right, so with this, we explained the angled brackets here and this
03:18 So it avoids that some funny guy would come in here and—instead of just giving a number at the end—type some funny URL, right? This is just not going to work because the path converter checks whether this is an integer—what gets cut off here, the rest of this. And if it isn’t, then it just says, “Okay, I’m not passing this forward.” This avoids that we would run into an error later, because we need the primary key to be an integer to correctly query our database. We wouldn’t find anything here.
This catches it early and just tells us, “Nope, this is not going to work.” And something like this comes in, a
1, then this can be converted to an integer, and it’s going to give it a go-ahead and pass
1 forward to
project_detail(), to the function. Inside of the function, then, we’re going to use it to query our database for this very specific entry that we’re looking for. Next, let’s head over to
views and build out the code logic that we’ve just been talking about. So, heading over to
views, we now want to create a second view function.
Okay. And that means we can use it, right? We want to query for one
Project, so I’m going to say
project = Project.objects.get(), and this code looks familiar because it’s exactly what we’ve been using inside of the Django shell, before, to query our database.
We’re doing the exact same thing and we’re giving it, here, the number that comes from the URL. So if a user puts in a
1, it’s going to pass forward the
1 here and query our database for the first entry. If it’s a
2, for the second one, et cetera.
project_detail(). We’re passing in the
request—as always, in Django. In this case, what differentiates it from the other one before is from our
urls file, we’re getting the information that it cuts off from the URL and passes forward to
project_detail(). We’re catching it here, and then we’re using it in order to be able to query our database, to get a very specific
Project back from it.
The rest is the same as above: we’re redirecting forward to a template and we’re passing this
Project object that we pulled out of the database so that we can then later render it in our template. Let’s look at this in an overview.
07:29 it cuts it off. It checks: is it an integer? In this case, yes. And passes it forward under this variable name to our new view function. In there, we use it to query the database and finally return the object that we got from there and pass it forward to the template.
I’m here at our page. We wanted to try, “Can I access the first resource if I type this in there?” All right! We’re getting somewhere. We’re getting a familiar error, it’s telling us
TemplateDoesNotExist. Right. We said, “Forward to
detail.html,” but we don’t have this template yet. So let’s go ahead, follow Django’s tip, and build out this template.
And there it is! Perfect. So, it’s working. And now, if I go to the second one, there we are. We’re finding the second
Project object. I’m going to make this a bit more readable real quick, but this is already a success for us.
And now, we have all the information from our database displayed here on the details page. I’m now on number
2, but I can easily switch to number
1 and I get all the different information here. All right, great! With this code, we built out the functionality to actually display a single resource.
Become a Member to join the conversation.