If you take a look at our URL structure right now, we’ve got / for all postings, /postings/archive/slug for individual posts, and /postings/topic/slug for topical listings. There are three URLs that people might expect to use but that don’t have anything matching them: /postings, /postings/archive, and /postings/topic. The latter two I’ll leave to you as an exercise. It might make sense to limit the main page to only the top 20 postings and put the rest of them on the archive page, and perhaps show a listing of all available topics on the topic page.
But what about /postings? It makes sense for /postings to show the same information that the main page shows. Perhaps some day, when the site will contain a blog section, a news section, an entertainment section, and the main page will reflect that, relegating the blog postings to the /postings URL will make sense. But for now, /postings and / are the same thing.
Rather than have two URLs that display the same information, we can redirect one URL to another one.
In urls.py for the postings project, add another line:
(r'^$', 'goHome'),
Because this is in the posting’s urls.py, the URL automatically begins with postings/. By using the regular expression for “nothing”, this line will match only postings/ and nothing else. When matched, it will call the goHome function.
So, in views.py, add goHome:
def goHome(request):
homePage = reverse('Blog.postings.views.listPosts')
return HttpResponseRedirect(homePage)
You’ll notice two new functions here: reverse and HttpResponseRedirect. Import them at the top of views.py.
from django.http import HttpResponseRedirect
from django.core.urlresolvers import reverse
If you now go to http://127.0.0.1:8000/postings/ you will be immediately redirected to http://127.0.0.1:8000/. The “reverse” function is a lot like the “url” template tag. It takes the name of a view and returns the URL that the view belongs to. HttpResponseRedirect is like render_to_response, except that it creates a response specifically optimized for redirects.
