summaryrefslogtreecommitdiff
path: root/docs/ref
diff options
context:
space:
mode:
Diffstat (limited to 'docs/ref')
-rw-r--r--docs/ref/contrib/sites.txt53
1 files changed, 20 insertions, 33 deletions
diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt
index 8bb7b27f32..790e003453 100644
--- a/docs/ref/contrib/sites.txt
+++ b/docs/ref/contrib/sites.txt
@@ -80,11 +80,11 @@ This accomplishes several things quite nicely:
The view code that displays a given story just checks to make sure the
requested story is on the current site. It looks something like this::
- from django.conf import settings
+ from django.contrib.sites.models import get_current_site
def article_detail(request, article_id):
try:
- a = Article.objects.get(id=article_id, sites__id__exact=settings.SITE_ID)
+ a = Article.objects.get(id=article_id, sites__id__exact=get_current_site(request).id)
except Article.DoesNotExist:
raise Http404
# ...
@@ -131,49 +131,36 @@ For example::
# Do something else.
Of course, it's ugly to hard-code the site IDs like that. This sort of
-hard-coding is best for hackish fixes that you need done quickly. A slightly
+hard-coding is best for hackish fixes that you need done quickly. The
cleaner way of accomplishing the same thing is to check the current site's
domain::
- from django.conf import settings
- from django.contrib.sites.models import Site
+ from django.contrib.sites.models import get_current_site
def my_view(request):
- current_site = Site.objects.get(id=settings.SITE_ID)
+ current_site = get_current_site(request)
if current_site.domain == 'foo.com':
# Do something
else:
# Do something else.
-The idiom of retrieving the :class:`~django.contrib.sites.models.Site` object
-for the value of :setting:`settings.SITE_ID <SITE_ID>` is quite common, so
-the :class:`~django.contrib.sites.models.Site` model's manager has a
-``get_current()`` method. This example is equivalent to the previous one::
+This has also the advantage of checking if the sites framework is installed, and
+return a :class:`RequestSite` instance if it is not.
+
+If you don't have access to the request object, you can use the
+``get_current()`` method of the :class:`~django.contrib.sites.models.Site`
+model's manager. You should then ensure that your settings file does contain
+the :setting:`SITE_ID` setting. This example is equivalent to the previous one::
from django.contrib.sites.models import Site
- def my_view(request):
+ def my_function_without_request():
current_site = Site.objects.get_current()
if current_site.domain == 'foo.com':
# Do something
else:
# Do something else.
-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.
-
-.. function:: get_current_site(request)
-
- Checks if contrib.sites is installed and returns either the current
- :class:`~django.contrib.sites.models.Site` object or a
- :class:`~django.contrib.sites.models.RequestSite` object based on
- the request.
-
Getting the current domain for display
--------------------------------------
@@ -192,14 +179,14 @@ current site's :attr:`~django.contrib.sites.models.Site.name` and
Here's an example of what the form-handling view looks like::
- from django.contrib.sites.models import Site
+ from django.contrib.sites.models import get_current_site
from django.core.mail import send_mail
def register_for_newsletter(request):
# Check form values, etc., and subscribe the user.
# ...
- current_site = Site.objects.get_current()
+ current_site = get_current_site(request)
send_mail('Thanks for subscribing to %s alerts' % current_site.name,
'Thanks for your subscription. We appreciate it.\n\n-The %s team.' % current_site.name,
'editor@%s' % current_site.domain,
@@ -370,19 +357,19 @@ Here's how Django uses the sites framework:
* In the :mod:`redirects framework <django.contrib.redirects>`, each
redirect object is associated with a particular site. When Django searches
- for a redirect, it takes into account the current :setting:`SITE_ID`.
+ for a redirect, it takes into account the current site.
* In the comments framework, each comment is associated with a particular
site. When a comment is posted, its
- :class:`~django.contrib.sites.models.Site` is set to the current
- :setting:`SITE_ID`, and when comments are listed via the appropriate
- template tag, only the comments for the current site are displayed.
+ :class:`~django.contrib.sites.models.Site` is set to the current site,
+ and when comments are listed via the appropriate template tag, only the
+ comments for the current site are displayed.
* In the :mod:`flatpages framework <django.contrib.flatpages>`, each
flatpage is associated with a particular site. When a flatpage is created,
you specify its :class:`~django.contrib.sites.models.Site`, and the
:class:`~django.contrib.flatpages.middleware.FlatpageFallbackMiddleware`
- checks the current :setting:`SITE_ID` in retrieving flatpages to display.
+ checks the current site in retrieving flatpages to display.
* In the :mod:`syndication framework <django.contrib.syndication>`, the
templates for ``title`` and ``description`` automatically have access to a