Opened 9 years ago

Closed 4 years ago

#3422 closed New feature (wontfix)

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

Reported by: Jeroen van Dongen <jeroen at> Owned by: nobody
Component: Core (Other) Version: master
Severity: Normal Keywords: reverse resolver extra_options
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Say I have a main like this:

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

and in '' something like this:

urlpatterns = patterns('',
    (r'^$',        ''),

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

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 into account during resolving,
while the forward resolver does.

Change History (14)

comment:1 Changed 9 years ago by Jeroen van Dongen <jeroen at>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.

comment:2 Changed 9 years ago by Michael Radziej <mir@…>

  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 9 years ago by SmileyChris

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.

comment:4 Changed 9 years ago by mtredinnick

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.

comment:5 Changed 9 years ago by durdinator

Wouldn't this use case be better handled by using url names now?

comment:6 Changed 9 years ago by durdinator

  • Triage Stage changed from Accepted to Design decision needed

comment:7 Changed 9 years ago by mtredinnick

  • Triage Stage changed from Design decision needed to Accepted

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.

comment:8 Changed 6 years ago by subsume

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:9 Changed 6 years ago by subsume

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

comment:10 Changed 6 years ago by subsume

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:11 Changed 5 years ago by lrekucki

  • Severity set to Normal
  • Type set to New feature

comment:12 Changed 4 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:13 Changed 4 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:14 Changed 4 years ago by aaugustin

  • Resolution set to wontfix
  • Status changed from reopened to closed

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 !

Note: See TracTickets for help on using tickets.
Back to Top