#1192 closed enhancement (wontfix)
[patch] Make urlresolver configureable
| Reported by: | Owned by: | Adrian Holovaty | |
|---|---|---|---|
| Component: | Core (Other) | Version: | dev |
| Severity: | normal | Keywords: | |
| Cc: | django@… | Triage Stage: | Unreviewed |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Currently the urlresolver is fix in the http.base module, which doesn't allow to customize how url's get resolved.
This patch implements a new config variable URL_RESOLVER which points to a class that will be used for resolving the url, makeing it easy to customize the behaviour of the django installation. For example, you could easy implement a weblog hosting where USER.example.org ist the weblog of the user, without touching apache. Or even use a database driven resolver.
The class will be initialized a little bit different then the current RegexURLResolver, because the request object is very usefull for a resolver class.
This patch also implements a HostURLResolver which also matches the hostname through a regular expression.
Note: The urlpatterns a different for this resolver:
urlpatterns = (
(r'bla', patterns('',
...
)),
(r'^localhost$', patterns('',
# Uncomment this for admin:
(r'^admin/', include('django.contrib.admin.urls.admin')),
)),
)
But it's for more advanced yours anyway, but I think it will be usefull for many people. The HostURLResolver is not that big, so i put it into core.urlresolvers.
Attachments (3)
Change History (9)
by , 20 years ago
| Attachment: | django_urlresolve_patch.diff added |
|---|
comment:1 by , 20 years ago
| priority: | high → normal |
|---|
comment:2 by , 20 years ago
| Cc: | added |
|---|
comment:3 by , 20 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
I'm closing this as a wontfix for now, but people can feel free to make this patch to their own code.
comment:4 by , 20 years ago
If i would strip down the patch to the absolut required changes, would possible to reopen and check it in ?
It's not that it's useless, i think it is usefull for many people not only me. People already asked on the mailing lists how to make subdomain specific resolvers. In my opinion it's a design flaw to have only possible way to resolve urls in a very flexible framework.
by , 20 years ago
| Attachment: | url_resolver2.diff added |
|---|
stripped down version of the patch + some changes to regexp urlresolver that allows easier customizations in custom resolvers
by , 20 years ago
| Attachment: | url_resolver3.diff added |
|---|
stripped down version of the patch + some changes to regexp urlresolver that allows easier customizations in custom resolvers. fixed typo
comment:7 by , 18 years ago
| Version: | magic-removal → SVN |
|---|
Could this be reopened for discussion?
It's a fairly simple change that seems to fit the design philosophies and would eliminate some patchqueues against core.
comment:8 by , 17 years ago
A vote for this. Host is part of URL and thus should be available in urlpatterns.
patch v1