#21927: URL namespacing improvements
--------------------------------------+------------------------------------
Reporter: aaugustin | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Core (URLs) | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by mrmachine):
Indeed, an app author ideally shouldn't need to do anything special (hard
coding the app name or namespace) when reversing the app's own URLs
because it is at the project level, outside the control of the app author,
where app URLs are installed into the root URLconf and optionally with a
namespace, either to avoid conflict with another installed app or to
install one app more than once at different URLs.
This means that app authors must provide instructions to the effect that
"my app must be installed within a namespace with an app_name and at least
once with a namespace of FOO" or some other work-around like the one you
have mentioned.
Django should automatically provide a default "current app" hint to
`reverse()` and `{% url %}` when URLs are reversed within the context of a
request/response cycle where the requested URL is installed into the root
URLconf with a namespace. Django can get this information from
`request.resolver_match`early in the request/response cycle and make it
available to `reverse()` via thread local storage. The use of thread local
storage is just one idea, I would be open to any others.
Apps should not themselves need to know anything about the namespace that
they are installed into (if any). App authors should reverse URLs using
their name only, as defined in the app's URLconf, and project developers
should be able to install that URLconf with any arbitrary namespace as
they see fit. Django should know when a URL is being reversed within the
context of that app, and provide the current app hint automatically based
on the configuration provided by the project developer.
See #22203 which proposes a default current app via thread local storage
but was closed as wontfix, and the corresponding google groups thread:
https://groups.google.com/forum/#!topic/django-developers/mPtWJHz2870
Also see #11642 which proposes to allow app authors to define a default
app name/namespace, similar to the earlier comment above by alanwj.
--
Ticket URL: <https://code.djangoproject.com/ticket/21927#comment:3>
Django <https://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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.dc67d8b22da4382553a30bee933f0b59%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
