#24430 closed New feature (wontfix)
wildcard matching and reversing of URLs
Reported by: | Anshuman Aggarwal | Owned by: | nobody |
---|---|---|---|
Component: | Core (URLs) | Version: | 1.7 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Example:
urlpatterns += patterns('', (r'^\w+/', include(admin.site.urls),), )
All links generated by the admin site with this url show a 'x'
for example : /x/<app_name>/<model_name>/
instead of the result of the matching wild card 'ABC' from ABC/<app_name>/<model_name>
the problem is that reverse can not know what to put in the wild card without having the path or the request as context.
Solution: add an optional parameter to reverse which is the request and the reverse can happen with the context of the request which is found acceptable in case the request parameter is not none.
Change History (7)
comment:1 by , 10 years ago
Description: | modified (diff) |
---|
comment:2 by , 10 years ago
Isn't that something that can be solved by simply naming that wildcard group and passing the captured kwarg
to reverse
later on?
comment:3 by , 10 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Yes. It seems incorrect to always assume that captured params from the request's path should always be used in reverse()
. If you find this argument unconvincing and want to discuss this further, please use the DevelopersMailingList, thanks.
comment:4 by , 10 years ago
Sorry for the delay in responding to the queries:
Tim,
Here is the use case below:
For each window that is open with a particular admin, I want to use it for a different tenant of a multiple tenant (SAAS) site.
eg. SAAS_TENTANT/<app-name>/<model-name>
This URL setup allows me to filter out the appropriate rows for the admin to show for a particular SAAS for a particular tab
Charettes,
It can't be solved with a named wildcard group because the existing admin does not provide any hooks for extending the same, short of overriding every single admin view function individually and adding logic in each
Please review in light of the above use case. I would like to see a clean way of doing this way as it will likely improve on the DRY and reusability of code
follow-up: 6 comment:5 by , 10 years ago
Multiple admin sites can already be deployed in same URLConf.
You'd just have to create a namespaced admin site for each of you tenants or write an URLResolver that does it for you.
comment:6 by , 10 years ago
Replying to charettes:
Multiple admin sites can already be deployed in same URLConf.
You'd just have to create a namespaced admin site for each of you tenants or write an URLResolver that does it for you.
Multiple admin sites are fine but seem to require each tenant to have a code entry in the URL Conf. Problem is that we need the namespaced admin sites to be dynamic since tenants needs to be added at any time without code intervention.
we write a URL Resolver, how will we get Django admin to use that URL resolver instead of the default django.core.urlresolvers.reverse etc?
this is why the wildcard support was proposed
comment:7 by , 10 years ago
I suggest you have a look at how LocaleRegexURLResolver
work. You just have to write and URLResolver that get or create a tenant specific admin site in a thread safe way and delegate the true url resolving to tenant_adminsite.urls
. It's definitely doable.
If you need help creating such a resolver I suggest you have a look at our different support channels since this ticket tracker isn't the right place to get help.
Keep in mind that your use case is very specific and that even if we added a request argument to the reverse
tag we'd have to either make the request a thread local object (this is not going to happen) or convert all the admin reverse calls (direct or through {% url %}
) to pass the request along. And I'm not even talking about third party admin apps that would require to also be converted.
There's already a supported and documented way of namespacing and deploying multiple admin sites and from what I can see it's perfectly suitable for your use case.
What's the use case for allowing the admin to be accessed at a wildcard URL?