Opened 16 years ago
Closed 9 years ago
#8952 closed New feature (wontfix)
Refactor a Django "site" to be just another view function
Reported by: | simon | Owned by: | Y3K |
---|---|---|---|
Component: | contrib.sites | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Someday/Maybe | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
At the moment middleware applies globally (unless you use the decorator_from_middleware hack). A Django powered site is essentially a thing that takes an HTTP request and returns an HTTP response. We should refactor things a bit so the highlest level of a Django site is just another view, which can compose bits of middleware and a URL dispatcher. This way Django applications end up composed of nested view functions, URL dispatchers and middleware which is really elegant. It won't be easy to do this due to lots of existing code expecting things to be how they are at the moment, but it's worth investigating.
Change History (11)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:3 by , 16 years ago
Component: | Uncategorized → Contrib apps |
---|
comment:4 by , 14 years ago
Component: | Contrib apps → contrib.sites |
---|
comment:5 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
follow-up: 7 comment:6 by , 13 years ago
Easy pickings: | unset |
---|---|
Triage Stage: | Design decision needed → Someday/Maybe |
UI/UX: | unset |
I'm not sure if it's useful to keep this ticket open after three years. Several paradigms have shifted since then.
follow-up: 8 comment:7 by , 13 years ago
Replying to aaugustin:
I'm not sure if it's useful to keep this ticket open after three years. Several paradigms have shifted since then.
FWIW I think this is a really good idea - I don't see anything that's shifted that would make this inapplicable. It'd be one (significant) step towards reducing the dependency on global settings everywhere.
I'm not in favor of closing this ticket, but Someday/Maybe is an appropriate state for it. I'd be happy to upgrade it to Accepted, though, if someone came along who was serious about working on it :-)
comment:8 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Triage Stage: | Someday/Maybe → Ready for checkin |
Version: | 1.0 → master |
Replying to carljm:
FWIW I think this is a really good idea - I don't see anything that's shifted that would make this inapplicable. It'd be one (significant) step towards reducing the dependency on global settings everywhere.
I'm not in favor of closing this ticket, but Someday/Maybe is an appropriate state for it. I'd be happy to upgrade it to Accepted, though, if someone came along who was serious about working on it :-)
Hello carljm, nice to meet you.
I'd like to review and work on this, if it stills beign a valid ticket. I don't get what's the new desired behaviour exactly, but it sounds interesting.
- I assigned this to me since it have been forgotten for years, I don't think anyone else would be interested on it.
- Its version from 1.0 to master, because the feature would be added to it instead of 1.0
- Its state has been changed to Ready for Checkin, I assume would be before Accepted, since I don't know if after 4 years we'll be interested on Accept it.
Thanks.
follow-up: 10 comment:9 by , 9 years ago
Keywords: | djangocon removed |
---|---|
Triage Stage: | Ready for checkin → Someday/Maybe |
Hi, please see the triage workflow to understand what "Ready for checkin" means. You are welcome to work on this if you like, although it seems non-trivial so I wouldn't recommend this as a first contribution, especially if you don't have an idea of where to start. You'll need to come up with a design plan and present it on the DevelopersMailingList to get feedback on your plan. Once that plan is approved, we can move the ticket to "Accepted". Thanks!
comment:10 by , 9 years ago
Replying to timgraham:
Hi, please see the triage workflow to understand what "Ready for checkin" means. You are welcome to work on this if you like, although it seems non-trivial so I wouldn't recommend this as a first contribution, especially if you don't have an idea of where to start. You'll need to come up with a design plan and present it on the DevelopersMailingList to get feedback on your plan. Once that plan is approved, we can move the ticket to "Accepted". Thanks!
Oh! That was the page I was looking for and couldn't find, thank you! (maybe an icon with help text next to the Triage status select would be neat).
By the way, nice to meet you Tim!
Regard the ticket, I don't know yet what's exactly the goal behind it, but I feel pretty confident about beign capable to work on it. I've been a Django user since 0.7 or so.
Would be possible to get a little more explicit example about the idea behind this ticket so I can come up with a plan?
Thank you.
comment:11 by , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
Aymeric was right here, and I was wrong. This is the sort of huge refactor that's unlikely to be successful unless taken on by an experienced core developer, and may not even be feasible then. I still think it would be interesting to see what could be done along these lines, but I don't think there's any value to keeping it open as a ticket.
Getting reverse to work will be really hard.