url configuration: include in combination with extra options messes up reverse resolving

[Jeroen van Dongen <jeroen at jkwadraat.net>]

Say I have a main urls.py like this:

urlpatterns = patterns('',
    (r'^xxx/weblog/',        include('myapps.blog.urls'), {'weblog_id': 'foo'}),
    (r'^yyy/weblog/',        include('myapps.blog.urls'), {'weblog_id': 'bar'}),
)

and in 'myapps.blog.urls' something like this:

urlpatterns = patterns('',
    (r'^$',        'myapps.blog.views.index'),
)

Then when a I visit '/yyy/weblog/', the blog's index view would get the parameter 'weblog_id' with
value 'bar' and presents the correct weblog (i.e. the resolver correctly finds that it needs to
use the second line from urls.py).

However when I then do a reverse url lookup in my view, passing weblog_id='bar' as parameter,
it will latch onto the first entry and return '/xxx/weblog/' instead of '/yyy/weblog'.

Apperently the reverse resolver does not take the extra options from urls.py into account during resolving,
while the forward resolver does.

[Jeroen van Dongen <jeroen at jkwadraat.net>]

Currently I don't have the time to look into it any further myself, and have worked-around it by putting the information in the url for the moment.

[Chris Beaven]

Since you can't provide the extra options to reverse, there is no way of it knowing which match you want. They both resolve to the same view, which is all that reverse wants, so it is picking the first match.

So the real problem you want fixed here is to be able to pass extra options to reverse which must also match.

[Malcolm Tredinnick]

Passing extra options to reverse() is a pain if they are anything other than strings or numbers -- can't think of a non-ugly to pass in a dictionary from a template and you're completely doomed when it comes to more generic objects (e.g. querysets or other class instances). So we probably can't solve this completely generically.

Passing in strings and numbers should be possible, I guess. There are use-cases for this.

[durdinator]

Wouldn't this use case be better handled by using url names now? ​http://www.djangoproject.com/documentation/url_dispatch/#naming-url-patterns

[Malcolm Tredinnick]

I'm happy for this to be implemented by anybody who understands the limitations in comment 4 and providing it's documented very well to explain that.

[Yeago]

OP seemed mistaken in thinking that these args factored into the resolving of a URL. Malcolm sees a use case but nobody's really chimed in in a few years so I think its safe to close. Please forgive my overreach if this is an inappropriate move. I've never heard of anyone expecting this behavior from extra arguments and for those who do want the specificity, there's named urls.

[Yeago]

reopening this. I misunderstood the original problem but its a rather obscure way to set up one's urls.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Aymeric Augustin]

I'm going to close this ticket, for three reasons:

• As explained by Malcolm, this feature would suffer from severe limitations. It may have been sufficient to document them 6 years ago; I'm not sure it's realistic any more. The limitations will cause confusion.
• The example given in the bug report is very close the the documentation's example for ​naming URLs. Named URLs are a solid solution in this situation.
• The problem is rather unfrequent, judging by the lack of activity on this ticket.

Malcolm, if you still think this should be supported (to some extend) by the URL resolver, please reopen !