Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request/Idea Autmatically try all host confs. #19

Open
apollo13 opened this issue Dec 29, 2014 · 4 comments
Open

Feature Request/Idea Autmatically try all host confs. #19

apollo13 opened this issue Dec 29, 2014 · 4 comments

Comments

@apollo13
Copy link
Collaborator

The ability to override the url tag is a great help for 3rd party apps, but I think instead of falling back to the default host, all host confs should be tried (maybe behind a setting): Assuming a site hosts a blog, forum and a wiki it would be great if the url tag would just try to reverse on all available host confs. This obviously only works for the cases where the subdomain is static, but I think this is a relatively common scenario. Is this something you'd support, if yes I'd see what I can do about that.

Implications would be that the urlnames have to be unique, or otherwise just let the first match win, but I think that urlnames are and should be unique anyways. Performance wise there should be no downside either, as having a single domain with all urls would require iteration over all anyways…

@jezdez
Copy link
Member

jezdez commented Dec 29, 2014

Hmm, I like the idea and agree that hostconfs with no parameters are the most common case. I think I'll postpone that till the next release though since I bet it's going to be a messy refactor yet again.

@apollo13
Copy link
Collaborator Author

Opened PR #20 with an implementation.

@jaddison
Copy link

I love the idea of this. Not having to pass scheme and host when resolving a URL makes sense to me - I don't think I'm likely to have 'shared' urls.

@jaddison
Copy link

I haven't thought it through particularly, but wouldn't it make some sense if this were merged that this functionality should exist for reverse() as well as the the {% url %} template tag? I imagine this would require early process monkey-patching as it isn't as simple as calling add_to_builtins as you would for template tags.

This would help view code in 3rd party apps to reverse() the correct URLs, I believe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants