On Tue, Oct 20, 2009 at 11:38 PM, Ivan Sagalaev <[email protected]> wrote: > > Russell Keith-Magee wrote: >> On the 'missing something' front, reverse() now takes a 'current_app' >> argument that gives context to the app lookup, which resolves the >> ambiguity from the point of view of the reverse() function. > > I saw this one. It doesn't work in this case exactly beacuse of this: > >> This solves the problem as long as applications have been built to >> provide a namespace. > > Which means an app knows its exact namespace. > >> However, this doesn't fully address the 'bug' you >> describe - an application that hasn't been built to accept namespaces >> will have problems if it is deployed in a namespace. > > There's important detail here. > > One thing is a namespace-ignorant application that just uses reversing > the old way. I don't think we can fix it in any way except saying > somehow "don't install this app under a namespace" (as you suggested). > > Another thing is an application that is being written now and that wants > to be namespace-aware. The problem is that while an application knows > that it can be included under a namespace it doesn't care under which > one exactly. > > As far as I can tell it can be solved by keeping views in > resolver.reverse_dict as it was before namespaces were introduced as > well as in namespace_dict and app_dict. This way they could be found > both by specifying a name with or without namespace. However it doesn't > solve the problem when you have two instances of the same application. > For this we should have a way for an application to know which instance > of it is "current". Which means tying reversing to a request (right?). > At this point I didn't come up with anything more useful...
Apologies for taking so long to get back to you on this. For this last case - building a new app that you want to be namespace aware - I think the Django admin already implements the model that needs to be followed here. I can't think of any obvious way to allow for an application to be 'namespaceless', as well as potentially one of many in a namespace. Admin solves this by *always* requiring a namespace - even if that's just the default application namespace. Django's URL namespace lookup makes the simple case easy, (i.e., admin:named_url works, regardless of how you have deployed admin), while allowing for multiple namespaces. Personally, I don't think it's too onerous for us to say that namespaces won't work unless you write an app to use them, and if you write an app to use namespaces, then you have to use them when you deploy. All this leaves is catching (and preventing) the case of deploying applications that aren't namespace aware inside a namespace. For this... patches welcome :-) Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
