Making redirects work properly in views for "include"d URLconfs

[nimrod.abing@…]

Here is a quote from the Django manual ​http://www.djangoproject.com/documentation/0.96/url_dispatch/

---

Including other URLconfs

At any point, your urlpatterns can “include” other URLconf modules. This essentially “roots” a set of URLs below other ones.

For example, here’s the URLconf for the Django website itself. It includes a number of other URLconfs: from django.conf.urls.defaults import *

urlpatterns = patterns('',
    (r'^weblog/',        include('django_website.apps.blog.urls.blog')),
    (r'^documentation/', include('django_website.apps.docs.urls.docs')),
    (r'^comments/',      include('django.contrib.comments.urls.comments')),
)

Note that the regular expressions in this example don’t have a $ (end-of-string match character) but do include a trailing slash. Whenever Django encounters include(), it chops off whatever part of the URL matched up to that point and sends the remaining string to the included URLconf for further processing.

---

OK, so I need to make some of my views reusable between different sites but I need them to be under different "roots". As an example I use the contrib.comments module...

In site 1:

urlpatterns = patterns("",
    (r'^comments/', include('django.contrib.comments.urls.comments')),
    # ... other URL's here...
)

In site 2:

urlpatterns = patterns("",
    (r'^feedback/', include('django.contrib.comments.urls.comments')),
    # ... other URL's here...
)

I was trying to find a way for redirects to work in my views so that the redirects work no matter where the URL's were rooted using include() . I could not find any obvious way from the documentation so I poked around in the source for django.contrib.comments.views.userflags. I found the following:

return HttpResponseRedirect('%sdone/' % request.path)

I think the above information should be included in the documentation for "Including other URLconfs" or perhaps ​http://www.djangoproject.com/documentation/0.96/tutorial03/#simplifying-the-urlconfs. The current wording seems to imply that once the "root" has been chopped off that information is simply "gone".

While this info is found in the source, like any sensible user I always go to look into the Documentation *before* poking around in the source.

[James Bennett]

The solution to this (in trunk) is to use reverse and named URL patterns, both of which are documented.