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 simon, 16 years ago

Getting reverse to work will be really hard.

comment:2 by Jacob, 15 years ago

Triage Stage: UnreviewedDesign decision needed

comment:3 by Thejaswi Puthraya, 15 years ago

Component: UncategorizedContrib apps

comment:4 by Gabriel Hurley, 13 years ago

Component: Contrib appscontrib.sites

comment:5 by Luke Plant, 13 years ago

Severity: Normal
Type: New feature

comment:6 by Aymeric Augustin, 12 years ago

Easy pickings: unset
Triage Stage: Design decision neededSomeday/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.

in reply to:  6 ; comment:7 by Carl Meyer, 12 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 :-)

in reply to:  7 comment:8 by Y3K, 9 years ago

Owner: changed from nobody to Y3K
Status: newassigned
Triage Stage: Someday/MaybeReady for checkin
Version: 1.0master

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 by Tim Graham, 9 years ago

Keywords: djangocon removed
Triage Stage: Ready for checkinSomeday/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!

in reply to:  9 comment:10 by Y3K, 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 Carl Meyer, 9 years ago

Resolution: wontfix
Status: assignedclosed

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