Opened 18 years ago

Closed 12 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 jkwadraat.net> Owned by: nobody
Component: Core (Other) Version: dev
Severity: Normal Keywords: urls.py 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

Description

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.

Change History (14)

comment:1 by Jeroen van Dongen <jeroen at jkwadraat.net>, 18 years ago

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

Triage Stage: UnreviewedAccepted

comment:3 by Chris Beaven, 18 years ago

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 by Malcolm Tredinnick, 18 years ago

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 by durdinator, 17 years ago

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

comment:6 by durdinator, 17 years ago

Triage Stage: AcceptedDesign decision needed

comment:7 by Malcolm Tredinnick, 17 years ago

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 by Yeago, 14 years ago

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 by Yeago, 14 years ago

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

comment:10 by Yeago, 14 years ago

Resolution: wontfix
Status: closedreopened

comment:11 by Łukasz Rekucki, 14 years ago

Severity: Normal
Type: New feature

comment:12 by Aymeric Augustin, 13 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:13 by Aymeric Augustin, 13 years ago

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:14 by Aymeric Augustin, 12 years ago

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