#11559: urlresolvers.reverse do not work with namespaced urls and captured
parameters in parent urlconf
----------------------------------------+-----------------------------------
          Reporter:  kmik...@gmail.com  |         Owner:  nobody
            Status:  new                |     Milestone:        
         Component:  Core framework     |       Version:  SVN   
        Resolution:                     |      Keywords:        
             Stage:  Someday/Maybe      |     Has_patch:  0     
        Needs_docs:  0                  |   Needs_tests:  0     
Needs_better_patch:  1                  |  
----------------------------------------+-----------------------------------
Comment (by chipx86):

 Curious if there's been any further discussion with this change. I've been
 trying to deploy an instance of the admin UI with a dynamic prefix
 (basically, hosting instances of a webapp grouped by some identifier), and
 have a custom subclass of AdminSite that can take the parameters and do
 the right thing.

 Now, this works, except that reversing admin URLs fails because of the way
 namespaces and captured arguments in the prefix of the URL works. This
 behavior has actually delayed our launch by about a week, so I'm eager to
 find a solution of some sort. I think where things seem confusing is that
 namespaced URLs just do not work the way standard URLs do.

 I played around with a couple patch ideas. One thing off the top of my
 head would be to have the namespaces dictionary build up the possible
 matches in place of the raw prefix. In a sense, it'd act like
 reverse_dict, except keyed off by namespace. Then the right possibilities
 could be received based on namespace.

 The trick at that point would be to pass that information to
 RegexURLResolver.reverse. Maybe the namespace could be passed to it, or
 the list of possibilities to use instead of those in reverse_dict.

 Or I may be on totally the wrong path. However, from the CC list and my
 own experiences, it doesn't seem that the current design is really
 sufficient for more advanced use, and I'd be happy to work on this but
 want to make sure I'm not about to waste any time by going in a direction
 you guys don't want to go in.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/11559#comment:17>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Reply via email to