Sites Framework: RequestSite and get_current

[Gabriel Hurley]

I went to triage a few tickets tonight, and noticed that #8960,
#10235, #10608 and #13814 have all arrived at essentially the same
conclusion: there needs to be a single idiomatic way to get either the
current Site object if contrib.sites is installed, or a RequestSite
object if not. All four tickets use the same bit of code, the argument
really only lies in where to put it.

#10235 adds it as a utility function in contrib.sites.models, #13814
as a separate method on SiteManager, and #8960 and #10608 basically
just copy and paste where needed. I'm of the opinion it should have
its own home in contrib.sites, but where, and under what name?

If we can agree on where this bit of code should live, I'd be happy to
get all of these tickets fixed in one fell swoop. For reference, #8960
which has been bumped out of several releases now and is prime 1.3
material.

Suggestions?

All the best,

- Gabriel

[Gabriel Hurley]

I should add that #10909 is another ticket that ultimately revolves
around getting a Site/RequestSite object to have access to the current
domain. Easily fixed once this function/method exists.

While I'm at it, #10944 would be moved one step closer by having a
consistent way to get the current Site/RequestSite as well.

- Gabriel

[bur...@gmail.com]

Hi Gabriel, everyone,

I'd also like if such function can support option "developer provides
function that knows the current site based on the request".
That means, "get my site" function ultimately needs a backend connector!

I think this might be fixed in the way we did with urlconf:
http://docs.djangoproject.com/en/dev/topics/http/urls/

So it will be taken from request:
request.site with default implementation to LazySite, with default
implementation of Site.objects.get_current() if sites_installed() or
RequestSite(request).

That implementation would be overriden with middleware

What do you think?

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>

--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

[Luke Plant]

On Thu, 2010-09-30 at 23:48 -0700, Gabriel Hurley wrote:
> I went to triage a few tickets tonight, and noticed that #8960,
> #10235, #10608 and #13814 have all arrived at essentially the same
> conclusion: there needs to be a single idiomatic way to get either the
> current Site object if contrib.sites is installed, or a RequestSite
> object if not. All four tickets use the same bit of code, the argument
> really only lies in where to put it.
>
> #10235 adds it as a utility function in contrib.sites.models, #13814
> as a separate method on SiteManager, and #8960 and #10608 basically
> just copy and paste where needed. I'm of the opinion it should have
> its own home in contrib.sites, but where, and under what name?

I think a stand-alone function in contrib.sites.models is fine, called
`get_current_site` (or some other sensible colour of your choosing).
Since both Site and RequestSite already live there, it seems a good
place.

Thanks for your work on this,

Luke

--
"Despair: It's always darkest just before it goes pitch black."
(despair.com)

Luke Plant || http://lukeplant.me.uk/

[Gabriel Hurley]

I can see why you might want control at the middleware level, but I'm
not sure that's the only/best way to accomplish that goal, and it
seems like the subject of a totally separate ticket to me. I'd rather
see this set of redundant problems solved in a simple fashion rather
than get into a debate over implementing a different feature...

just my two cents,

- Gabriel

> > For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.

[Luke Plant]

On Fri, 2010-10-01 at 12:08 -0700, Gabriel Hurley wrote:
> I can see why you might want control at the middleware level, but I'm
> not sure that's the only/best way to accomplish that goal, and it
> seems like the subject of a totally separate ticket to me. I'd rather
> see this set of redundant problems solved in a simple fashion rather
> than get into a debate over implementing a different feature...

Absolutely right, go ahead with your patch. If someone really cares
about the other feature (which seems a bit obscure to me), then they
will do the normal things required.

Thanks,

Luke

--
"DO NOT DISTURB. I'm disturbed enough already."

Luke Plant || http://lukeplant.me.uk/

[Gabriel Hurley]

There is now a ticket and a patch for this, which includes the utility
method and a rollup of fixes for the aforementioned tickets as
appropriate. Tests and docs included. Details are in the ticket
description:

http://code.djangoproject.com/ticket/14386

I'd love to get some feedback on it when possible.

Thanks!

- Gabriel

[bur...@gmail.com]

Hi Gabriel,

looking good!

--