RedirectView Class Helper

00:00 In the previous lesson, I showed you the four different ways of calling the redirect() shortcut. In this lesson, I’m going to show you the RedirectView class helper.

00:08 RedirectView is a convenience class that has a built-in view. A typical use for it is to call it directly from inside of an urls file.

00:16 I often use it this way to tell a browser that’s looking for the favicon in the root to go into the static/ folder where I usually store it.

00:24 You can also overload this class in order to customize it for your needs.

00:30 First off, an example of using this directly inside of the urls file. I’ll hit /inline_indirect/ and pass in the parameter camping.

00:40 Notice 'inline_redirect/' is defined with a parameter called term. It’s a string. The RedirectView class is directly used inside of the path as the view.

00:51 It is parameterized with a URL of where to go—in this case, Google—and the parameter can be altered using the %s mechanism. The query string for Google includes "%(term)s". The "%(term)s" portion will get filled in with the term from the path() URL.

01:11 When I call curl /inline_direct/ with camping, Google will get google.com/?q=camping.

01:21 And here’s that response. curl comes back with a 302 and the Location header is https://google.com with camping filled in where %(term)s was.

01:37 Looking at the same kind of example—but this time overloading the class—calling /inherit_redirect/ using the hiking parameter. /inherit_redirect/ is also parameterized with a term.

01:49 It calls SearchRedirectView. SearchRedirectView inherits from the RedirectView class. Inside of the views file, you can see that class. In this case, all I’ve done is override the .url attribute. The contents of the .url attribute are exactly the same as directly calling it in the previous example—"google.com", still using "%(term)s"—and this will get populated as before.

02:19 Same idea: the response comes back, redirect to google.com with the query string set to hiking.

02:27 In the third example, I’m going to override the entire method.

02:34 Calling the dev server, using /random_redirect/, passing in the parameter sailing.

02:43 The urls file maps to the RandomSearchView, which inherits from RedirectView.

02:51 Inside of the views file, lines 7 through 16 is the RandomSearchView class. The meat of it is the overridden get_redirect_url().

03:02 This is the method in the class that results in the redirect string. By overriding it, you can take complete control over what it does. In this particular example, I’m randomly picking one of the URLs defined in search_urls—lines 8 through 12—and when I’ve picked it, I parameterize it. Just like before, it supports the "%(term)s" mechanism, passing in the term parameter from the urls file.

03:28 The end result: Bing was randomly chosen and parameterized with sailing. There are a number of things that you can override if you’re subclassing RedirectView.

03:39 You can specify the .url attribute for a hardcoded string. Instead, you can set .pattern_name to specify a named URL pattern. There’s a boolean called .permanent which defaults to False, but if set to True uses a permanent redirect.

03:54 There’s another boolean called .query_string. If this is True, any query string that’s sent in with the original URL is appended to the redirect.

04:02 This also defaults to False. Overriding .get_redirect_url() allows you to fine-tune your control. If your method returns None, a 410 Gone status is sent back to the browser.

04:15 The default implementation of .get_redirect_url() checks for the .url attribute. If it doesn’t find it, then it checks for the .pattern_name attribute. Both the .url and .pattern_name attributes support the %s placeholders, passing in keyword arguments from the URL pattern. When should you use this class? Well, it’s an easy way of putting a redirect right inside of your urls file.

04:41 If you’re already using class-based views, overloading RedirectView would be consistent with your code. I’m not particularly a big fan of class-based views.

04:49 I find function-based views easier to read, and I would rather have a one-line function view with a redirect() shortcut call in it, than overload the class.

04:59 I tend to only use this myself if I’m directly overloading in the urls file. But if your codebase uses class-based views or you find them easier to understand, that’s what it’s there for. Next up, I’ll show you how to use parameters inside of your redirects.