> > An app doesn't necessarily have to use its own patterns. With that said, > it's up to the user to make sure it works if they are to mess with the > app_name. Two conflicting apps can be installed with different namespaces, > but there will always be a default (the last one, if there is no namespace > with the same name). With a consistent use of `current_app` (even if it's > not the *current* application used in the request), you can avoid problems. >
Right. So if I understand correctly, you can avoid problems even when installing two different apps into the same app namespace as long as you *always* supply `current_app` when reversing URLs? In which case, I don't think we need to worry about being able to change the app namespace to avoid conflicts (maybe we should even disallow it), and instead just make it easier to *always* supply `current_app`, which brings me to my next point. If possible, I'd like to add `current_app` to the request by default, but > that has been attempted before, and backwards compatibility is a problem. > That would allow an app to more reliably reverse its own urls, provided > that their code and templates are called from within their own application. > I'd take this a step further. In this comment -- https://code.djangoproject.com/ticket/21927#comment:9 -- I made a suggestion that Django set a `current_app` hint in thread local storage with a middleware class or even before middleware runs, and then have `reverse()` and `{% url %}` fallback to that default hint ONLY if no current app is explicitly provided via the current mechanisms, so it should be a relatively safe change. This should make it much more convenient and possible to reverse URLs correctly regardless of conflicting app namespaces, even in code that doesn't have access to the request object. For example, model methods that are executed in templates and do not have access to a `request` or `RequestContext` object. As far as I know, 1 thread = 1 request, so using thread local storage should be safe to provide such a hint for any code that executes in response to a request. For management commands, it would still need to be supplied explicitly. What do you think? Cheers. Tai. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ba7b83e0-8961-45f9-89f0-e45ce25224fb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
