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.

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 :-)

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.

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!

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?

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.