Welcome back, everyone, in this lecture, we're going to discuss your names and the reverse function
within Django.
As our websites get larger and more complex, we're going to end up adding more and more views and URLs
across the project and apps.
This leads to more instances where we're going to need to reference some existing page on our web.
For example, having a button that links to some other web page or URL path on some other web page across
our website.
So we keep linking across different pages, especially as the website gets larger and larger with more
and more pages.
Now, in this lecture, we're going to explore two key ideas.
One is that you are a parts inside that path function can actually have names associated with them that
can then be referenced across Jango and inside of a template.
This is a super powerful tool, and it's going to make your code way more maintainable and way more
robust.
And it follows what's known as the dry principle, which is don't repeat yourself.
Right now, we've have a few things that are hardcoded that are be much easier to actually refer to
a name to a URL.
Now, in order to use that with a view, Django also has a reverse function to find the corresponding
URL path for a given URL name.
So let me explain what the reverse function actually does through the use of this kind of thought experiment.
What's the typical flow for a web page that we've seen so far in Django?
Well, you have the user and that user types in some specific domain path for our URL and that says,
Hey, I'm looking for this specific URL for first app.
For sports, for instance, Django says no problem.
Let me look that up across my URL patterns list, which is going to be in my URLs, not py file.
Then, once it finds the match, it calls the corresponding view.
Now, what if the request for the URL is actually happening within the Vieuxtemps Pie file and not directly
from the user?
Remember that as our website gets more and more complex, there's going to be instances where we want
to redirect the user.
Maybe they just filled out a form and we want to redirect them to some other web page once they completed
that form.
Or maybe we're trying to implement that physical numbering where we associate the number one to the
top exports or a number two to finance, etc. So we already know we can have these sort of redirect
views that taken the request and then say, Hey, I would like to redirect them to this other URL.
And so far, we've technically been hard coding that other URL.
It's not as clear right now because we don't really have templates in play, but this was technically
hardcoded.
What Jango has is the capability to not hard code that and instead simply refer to a URL path by name.
So we end up doing is we have this reverse function.
So what you do is you pass in the name of the URL and later on we'll see how to assign the name to a
URL.
It's actually quite easy simply say name is equal to inside that path function and then that gives you
that web page or your URL object that you can then pass in for the HDP response.
Redirect.
So you'll end up calling the URL name inside a reverse and then pass that in to wherever you want to
redirect the user.
And typically, this is actually not done in two lines, you'll see the reverse call done inside ACP
Response Redirect or HDP response call.
Now, the reason it's called reverse is because you can think this is kind of happening in the reverse
of what's normal.
Normally, the URLs that PY file is looking for the view inside of used up high.
But this time around, it's kind of the reverse where inside we've used our PI and reverse is asking,
Hey, given this URL name, where's the corresponding URL?
That's kind of where it gets its name is the fact that this is going in reverse.
You're going from views to your URL instead of what's typical, which is here's the URL.
Now get me the view for it.
Instead, we're inside of views and then we're saying, Hey, what is actually happening inside URLs
for this URL name?
So let's go ahead and name a URL and then use that name inside a reverse call for Django.
All right.
Here I am.
Inside of my application, I have used up high and I also have the URLs that pay for the application.
What I'm going to do is on the path that actually takes in a string topic for the news view.
Remember, that's the one that takes in something like forward slash finance or forward slash sports.
I'm going to give this your URL a name, and let's go ahead and call it something like.
Topic.
Page now it's going to be super useful is now we can refer to this particular path inside of URL patterns
by topic page.
And you can even do that inside of your HTML template files.
Later on, we actually learn how to syntax things with Django and ginger.
So just this tool itself, the fact that you can name these paths inside URLs is going to make your
life a thousand times easier and is a huge deal for what we're about to learn.
I know it may seem really simple right now, but this is going to make your life a lot easier.
So we're going to save that change.
Notice, I'm just naming the topic one, and we're going to come back to views and take a look again
at this number page view.
Remember, this one was taking something that looked like this first, that poor size zero and then
try to transform it to something like that first step forward slash sports.
What are the issues right now is, let's say you revisit this and you have maybe a dozen more functions
and they're all in different orders and you come to this function view and you're looking at it and
you're trying to think, wait a minute, where is this actually redirecting to?
I just said topic, but I have so many views now in my project.
It's grown a lot more.
I have so many URLs.
I kind of have no idea what's actually happening by just putting in this random topic.
So what would be really nice here is if instead I could say, Hey, I had this topic.
I need you to do a reverse call for the topic page URL and then passed that topic into the path.
What would it actually look like?
You're going to see right now that upon revisiting this code after using reverse and then you are all
names, it's going to be a lot more readable and a lot more maintainable.
First thing you have to do is actually import reverse will say from Django that URLs import the reverse
function.
And then what we're going to do is down here.
I'll do this first in two lines.
So you can kind of see the change clearly is we're going to say that the web page we are redirecting
to.
Is going to say, hey.
Do a reverse lookup here, essentially for the URL and the actual page I want you to match to is going
to be called Topic Dash page.
Now remember this topic page actually takes in a parameter and needs that topic, and sometimes certain
parts are actually going to take in multiple parameters.
For example, remember we had one path that we're actually able to add up those numbers like one forward
slash to return back three.
So it's going to end up happening is you have a second parameter here and it can take an args or keyword
arguments.
So we're going to say ARGS is equal to and the always pass the Senate as a list, even if it's just
one item.
And in this case, we're going to pass in topic as the argument to be passed in here for this particular
argument for this path.
OK.
So then once we have that web page, I can simply put that here versus the topic.
Now you typically won't see this be done in two lines.
Instead, what's going to happen is you just cut this out.
And then paste it in here.
But before I do that, I want to just kind of do a quick overview what's actually happening here?
And hopefully you can see why this is going to be more readable if somebody were to come back to this
and say, Hey, what is some page of you doing?
They can kind of see that it gets a topic and they say, Oh, well, it's passing the topic to this
particular URL pathway.
So then they can just say, OK, well, which one was called topic page?
They would come to you, or I'll stop pie.
And then they would just look for the name here at the end.
And eventually, we all have names.
You'll say, Oh, now I see the topic page that this is actually going back to, because the way this
function was currently written was really quite weak.
And it kind of only worked because we just had to URL paths.
It would easily get broken more and more, especially as we expanded the number of views, a number
of URLs.
So right now, I have it in a much better position where I say, Hey, I'm looking for the Europe.
Half that is called topic page and by the way, said that this topic.
And that's where I want you to redirect to much cleaner, much easier to read and much better for maintenance.
So we're actually going to then cut this out.
And then paste that here, is that a Web page just to show you kind of the way you would typically see
this in Django?
So you have this reverse call in here topic page and then pass on the topic.
So that's it.
We're going to test this out.
Make sure it's running.
You technically won't see any changes from before, but let's go ahead and check it out anyway.
So say a Python match run server, and then I'm going to bring in the Chrome browser where I have the
page running.
So here I am at home view and right now I'm going to say got a first app?
Four zero hit enter, and it took me to the sports page, so it is doing the redirect, and let's try
it one more time with, let's say, to enter, and that's taking to the politics page.
Perfect.
So again, what's happening here is you now have this amazing name that you can refer to for this entire
path.
And that's going to have functionality across templates across many different types of jingle files,
and it has functionality within the views, especially when you call reverse here.
And then you just say, Hey, reverse, look up that URL path and then send that these arguments so
much clearer code and it's going to be a life saver for us later on in the course.
OK, that's it for this lecture.
I'll see if the next one where we actually connect this to a template instead of passing in just strings
for each of your responses.
I'll see you there.