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 , 18 years ago
comment:2 by , 18 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 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 , 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 , 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 , 17 years ago
Triage Stage: | Accepted → Design decision needed |
---|
comment:7 by , 17 years ago
Triage Stage: | Design decision needed → 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 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | new → 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 by , 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 , 14 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
comment:11 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:14 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → 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 !
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.