Fixed #14386, #8960, #10235, #10909, #10608, #13845, #14377 - standardize Site/RequestSite usage in various places.

Many thanks to gabrielhurley for putting most of this together.  Also to
bmihelac, arthurk, qingfeng, hvendelbo, petr.pulc@s-cape.cz, Hraban for
reports and some initial patches.

The patch also contains some whitespace/PEP8 fixes.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@13980 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Luke Plant 2010-10-04 14:20:47 +00:00
parent 96c11b29bd
commit 667d832e90
13 changed files with 220 additions and 120 deletions

View file

@ -107,7 +107,7 @@ This has the same benefits as described in the last section.
Hooking into the current site from views
----------------------------------------
On a lower level, you can use the sites framework in your Django views to do
You can use the sites framework in your Django views to do
particular things based on the site in which the view is being called.
For example::
@ -148,6 +148,16 @@ the :class:`~django.contrib.sites.models.Site` model's manager has a
else:
# Do something else.
.. versionchanged:: 1.3
For code which relies on getting the current domain but cannot be certain
that the sites framework will be installed for any given project, there is a
utility function :func:`~django.contrib.sites.models.get_current_site` that
takes a request object as an argument and returns either a Site instance (if
the sites framework is installed) or a RequestSite instance (if it is not).
This allows loose coupling with the sites framework and provides a usable
fallback for cases where it is not installed.
Getting the current domain for display
--------------------------------------