Opened 8 years ago

Closed 8 months 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: master
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 Changed 8 years ago by simon

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Getting reverse to work will be really hard.

comment:2 Changed 7 years ago by jacob

  • Triage Stage changed from Unreviewed to Design decision needed

comment:3 Changed 7 years ago by thejaswi_puthraya

  • Component changed from Uncategorized to Contrib apps

comment:4 Changed 5 years ago by gabrielhurley

  • Component changed from Contrib apps to contrib.sites

comment:5 Changed 5 years ago by lukeplant

  • Severity set to Normal
  • Type set to New feature

comment:6 follow-up: Changed 4 years ago by aaugustin

  • Easy pickings unset
  • Triage Stage changed from Design decision needed to 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.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 4 years ago by carljm

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 in reply to: ↑ 7 Changed 8 months ago by Y3K

  • Owner changed from nobody to Y3K
  • Status changed from new to assigned
  • Triage Stage changed from Someday/Maybe to Ready for checkin
  • Version changed from 1.0 to 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.

comment:9 follow-up: Changed 8 months ago by timgraham

  • Keywords djangocon removed
  • Triage Stage changed from Ready for checkin to 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 in reply to: ↑ 9 Changed 8 months ago by Y3K

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 Changed 8 months ago by carljm

  • Resolution set to wontfix
  • Status changed from assigned to 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.

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