Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#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 Tim Graham)

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 Tim Graham, 10 years ago

Description: modified (diff)

What's the use case for allowing the admin to be accessed at a wildcard URL?

comment:2 by Simon Charette, 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 Tim Graham, 10 years ago

Resolution: wontfix
Status: newclosed

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 Anshuman Aggarwal, 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

comment:5 by Simon Charette, 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.

in reply to:  5 comment:6 by Anshuman Aggarwal, 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 Simon Charette, 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.

Note: See TracTickets for help on using tickets.
Back to Top