I would be more in favor of seeing a new setting to configure
`get_current_site()` than seeing the existing `SITE_ID` setting shoehorned
into a new purpose (and being permanently misnamed for legacy reasons). For
the sake of allowing complete customization of the site lookup process I
suppose a new settings makes sense here.
As I noted on the ticket, I'm not entirely sure that deprecating
Site.objects.get_current_site() is necessary, and there are arguments to be
made for both sides. Avoiding user confusion is a good thing, but there are
cases where authors may want to make use of the Site model exclusively, in
which case the shortcut and its associated caching is still useful.
In response to Yuri:
1. You would not need the Sites Framework installed. The get_current_site
function works by checking to see if contrib.sites is installed, and
returning a RequestSite if not. RequestSite is just a generic object which
implements a common interface with the Site model. Using a custom callable
could similarly bypass any need for the Site model if so desired, or it
could simply be a different way to retrieve a Site object.
2. Allowing a custom callable solves the problem of being tied to a
particular model, because your custom callable can return an object of any
type you like so long as it implements the appropriate hooks (as RequestSite
does). This practice is generally referred to as "duck typing".
The "correct interface"--as I understand it--is that all authors should be
moving towards get_current_site() as the single point of entry for gaining
access to a Site-like object, and that you should not expect the returned
object to be a Site instance, but simply that it will behave like one and
have an equivalent base set of attributes and methods.
All the best,
- Gabriel
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
