Opened 10 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 10 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 10 years ago by Michael Radziej <mir@…>

Triage Stage: UnreviewedAccepted

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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.

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: AcceptedDesign decision needed

comment:7 Changed 9 years ago by Malcolm Tredinnick

Triage Stage: Design decision neededAccepted

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 Yeago

Resolution: wontfix
Status: newclosed

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 Yeago

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 Yeago

Resolution: wontfix
Status: closedreopened

comment:11 Changed 6 years ago by Łukasz Rekucki

Severity: Normal
Type: New feature

comment:12 Changed 5 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:13 Changed 5 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:14 Changed 4 years ago by Aymeric Augustin

Resolution: wontfix
Status: reopenedclosed

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