Django comes with an optional "sites" framework. It's a hook for associating\nobjects and functionality to particular websites, and it's a holding place for\nthe domain names and "verbose" names of your Django-powered sites.
\nUse it if your single Django installation powers more than one site and you\nneed to differentiate between those sites in some way.
\nThe sites framework is mainly based on a simple model:
\nA model for storing the domain and name attributes of a website.
The fully qualified domain name associated with the website.\nFor example, www.example.com.
A human-readable "verbose" name for the website.
\nThe SITE_ID setting specifies the database ID of the\nSite object associated with that\nparticular settings file. If the setting is omitted, the\nget_current_site() function will\ntry to get the current site by comparing the\ndomain with the host name from\nthe request.get_host() method.
How you use this is up to you, but Django uses it in a couple of ways\nautomatically via simple conventions.
\nWhy would you use sites? It's best explained through examples.
\nThe Django-powered sites LJWorld.com and Lawrence.com are operated by the\nsame news organization -- the Lawrence Journal-World newspaper in Lawrence,\nKansas. LJWorld.com focuses on news, while Lawrence.com focuses on local\nentertainment. But sometimes editors want to publish an article on both\nsites.
\nThe naive way of solving the problem would be to require site producers to\npublish the same story twice: once for LJWorld.com and again for Lawrence.com.\nBut that's inefficient for site producers, and it's redundant to store\nmultiple copies of the same story in the database.
\nThe better solution is simple: Both sites use the same article database, and an\narticle is associated with one or more sites. In Django model terminology,\nthat's represented by a ManyToManyField in the\nArticle model:
from django.db import models\nfrom django.contrib.sites.models import Site\n\nclass Article(models.Model):\n headline = models.CharField(max_length=200)\n # ...\n sites = models.ManyToManyField(Site)\nIni menyelesaikan beberapa hal cukup baik:
\nItu membiarkan pembuat situs menyunting semua isi -- pada kedua situs -- dalam antarmuka tunggal (admin Django).
Itu berarti cerita sams tidak harus menerbitkan kedua kali di basisdata; itu hanya mempunyai rekaman tunggal di basisdata.
Itu membiarkan pengembang situs menggunakan kode tampilan Django sama untuk kedua situs. Kode tampilan yang memperlihatkan cerita yang diberikan cukup memeriksa untuk memastikan cerita diminta pada situs saat ini. Itu terlihat sesuatu seperti ini:
\nfrom django.contrib.sites.shortcuts import get_current_site\n\ndef article_detail(request, article_id):\n try:\n a = Article.objects.get(id=article_id, sites__id=get_current_site(request).id)\n except Article.DoesNotExist:\n raise Http404("Article does not exist on this site")\n # ...\nSimilarly, you can associate a model to the\nSite\nmodel in a many-to-one relationship, using\nForeignKey.
For example, if an article is only allowed on a single site, you'd use a model\nlike this:
\nfrom django.db import models\nfrom django.contrib.sites.models import Site\n\nclass Article(models.Model):\n headline = models.CharField(max_length=200)\n # ...\n site = models.ForeignKey(Site, on_delete=models.CASCADE)\nIni mempunyai keuntungan sama seperti digambarkan di bagian terakhir.
\nAnda dapat menggunakan kerangka kerja situs di tampilan Django anda untuk melakukan hal-hal tertentu berdasarkan pada situs dimana tampilan sedang dipanggil. Sebagai contoh:
\nfrom django.conf import settings\n\ndef my_view(request):\n if settings.SITE_ID == 3:\n # Do something.\n pass\n else:\n # Do something else.\n pass\nOf course, it's ugly to hard-code the site IDs like that. This sort of\nhard-coding is best for hackish fixes that you need done quickly. The\ncleaner way of accomplishing the same thing is to check the current site's\ndomain:
\nfrom django.contrib.sites.shortcuts import get_current_site\n\ndef my_view(request):\n current_site = get_current_site(request)\n if current_site.domain == 'foo.com':\n # Do something\n pass\n else:\n # Do something else.\n pass\nThis has also the advantage of checking if the sites framework is installed,\nand return a RequestSite instance if\nit is not.
Jika anda tidak mempunyai akses ke obyek diminta, anda dapat menggunakan metode get_current() dari pengelola model Site. Anda harus kemudian memastikan bahwa berkas pengaturan anda mengandung pengaturan SITE_ID. Contoh ini adalah setara pada satu sebelumnya:
from django.contrib.sites.models import Site\n\ndef my_function_without_request():\n current_site = Site.objects.get_current()\n if current_site.domain == 'foo.com':\n # Do something\n pass\n else:\n # Do something else.\n pass\nLJWorld.com and Lawrence.com both have email alert functionality, which lets\nreaders sign up to get notifications when news happens. It's pretty basic: A\nreader signs up on a Web form and immediately gets an email saying,\n"Thanks for your subscription."
\nIt'd be inefficient and redundant to implement this sign up processing code\ntwice, so the sites use the same code behind the scenes. But the "thank you for\nsigning up" notice needs to be different for each site. By using\nSite\nobjects, we can abstract the "thank you" notice to use the values of the\ncurrent site's name and\ndomain.
Disini adalah contoh dari apa tampilan penanganan formulir kelihatannya:
\nfrom django.contrib.sites.shortcuts import get_current_site\nfrom django.core.mail import send_mail\n\ndef register_for_newsletter(request):\n # Check form values, etc., and subscribe the user.\n # ...\n\n current_site = get_current_site(request)\n send_mail(\n 'Thanks for subscribing to %s alerts' % current_site.name,\n 'Thanks for your subscription. We appreciate it.\\n\\n-The %s team.' % (\n current_site.name,\n ),\n 'editor@%s' % current_site.domain,\n [user.email],\n )\n\n # ...\nOn Lawrence.com, this email has the subject line "Thanks for subscribing to\nlawrence.com alerts." On LJWorld.com, the email has the subject "Thanks for\nsubscribing to LJWorld.com alerts." Same goes for the email's message body.
\nNote that an even more flexible (but more heavyweight) way of doing this would\nbe to use Django's template system. Assuming Lawrence.com and LJWorld.com have\ndifferent template directories (DIRS), you could\nsimply farm out to the template system like so:
from django.core.mail import send_mail\nfrom django.template import loader, Context\n\ndef register_for_newsletter(request):\n # Check form values, etc., and subscribe the user.\n # ...\n\n subject = loader.get_template('alerts/subject.txt').render(Context({}))\n message = loader.get_template('alerts/message.txt').render(Context({}))\n send_mail(subject, message, 'editor@ljworld.com', [user.email])\n\n # ...\nIn this case, you'd have to create subject.txt and message.txt\ntemplate files for both the LJWorld.com and Lawrence.com template directories.\nThat gives you more flexibility, but it's also more complex.
It's a good idea to exploit the Site\nobjects as much as possible, to remove unneeded complexity and redundancy.
Django's get_absolute_url() convention is nice for getting your objects'\nURL without the domain name, but in some cases you might want to display the\nfull URL -- with http:// and the domain and everything -- for an object.\nTo do this, you can use the sites framework. A simple example:
>>> from django.contrib.sites.models import Site\n>>> obj = MyModel.objects.get(id=3)\n>>> obj.get_absolute_url()\n'/mymodel/objects/3/'\n>>> Site.objects.get_current().domain\n'example.com'\n>>> 'https://%s%s' % (Site.objects.get_current().domain, obj.get_absolute_url())\n'https://example.com/mymodel/objects/3/'\nUntuk mengadakan kerangka situs ini, ikuti langkah-langkah ini:
\nMenambahkan 'django.contrib.sites' ke pengaturan INSTALLED_APPS anda.
Menentukan pengaturan SITE_ID:
SITE_ID = 1\nMenjalankan migrate.
django.contrib.sites registers a\npost_migrate signal handler which creates a\ndefault site named example.com with the domain example.com. This site\nwill also be created after Django creates the test database. To set the\ncorrect name and domain for your project, you can use a data migration.
In order to serve different sites in production, you'd create a separate\nsettings file with each SITE_ID (perhaps importing from a common settings\nfile to avoid duplicating shared settings) and then specify the appropriate\nDJANGO_SETTINGS_MODULE for each site.
Site objectLink to this heading#As the current site is stored in the database, each call to\nSite.objects.get_current() could result in a database query. But Django is a\nlittle cleverer than that: on the first request, the current site is cached, and\nany subsequent call returns the cached data instead of hitting the database.
If for any reason you want to force a database query, you can tell Django to\nclear the cache using Site.objects.clear_cache():
# First call; current site fetched from database.\ncurrent_site = Site.objects.get_current()\n# ...\n\n# Second call; current site fetched from cache.\ncurrent_site = Site.objects.get_current()\n# ...\n\n# Force a database query for the third call.\nSite.objects.clear_cache()\ncurrent_site = Site.objects.get_current()\nCurrentSiteManagerLink to this heading#If Site plays a key role in your\napplication, consider using the helpful\nCurrentSiteManager in your\nmodel(s). It's a model manager that\nautomatically filters its queries to include only objects associated\nwith the current Site.
Use CurrentSiteManager by adding it to\nyour model explicitly. For example:
from django.db import models\nfrom django.contrib.sites.models import Site\nfrom django.contrib.sites.managers import CurrentSiteManager\n\nclass Photo(models.Model):\n photo = models.FileField(upload_to='photos')\n photographer_name = models.CharField(max_length=100)\n pub_date = models.DateField()\n site = models.ForeignKey(Site, on_delete=models.CASCADE)\n objects = models.Manager()\n on_site = CurrentSiteManager()\nWith this model, Photo.objects.all() will return all Photo objects in\nthe database, but Photo.on_site.all() will return only the Photo objects\nassociated with the current site, according to the SITE_ID setting.
Taruh di jalan lain, dua pernyataan ini adalah sama:
\nPhoto.objects.filter(site=settings.SITE_ID)\nPhoto.on_site.all()\nHow did CurrentSiteManager\nknow which field of Photo was the\nSite? By default,\nCurrentSiteManager looks for a\neither a ForeignKey called\nsite or a\nManyToManyField called\nsites to filter on. If you use a field named something other than\nsite or sites to identify which\nSite objects your object is\nrelated to, then you need to explicitly pass the custom field name as\na parameter to\nCurrentSiteManager on your\nmodel. The following model, which has a field called publish_on,\ndemonstrates this:
from django.db import models\nfrom django.contrib.sites.models import Site\nfrom django.contrib.sites.managers import CurrentSiteManager\n\nclass Photo(models.Model):\n photo = models.FileField(upload_to='photos')\n photographer_name = models.CharField(max_length=100)\n pub_date = models.DateField()\n publish_on = models.ForeignKey(Site, on_delete=models.CASCADE)\n objects = models.Manager()\n on_site = CurrentSiteManager('publish_on')\nIf you attempt to use CurrentSiteManager\nand pass a field name that doesn't exist, Django will raise a ValueError.
Finally, note that you'll probably want to keep a normal\n(non-site-specific) Manager on your model, even if you use\nCurrentSiteManager. As\nexplained in the manager documentation, if\nyou define a manager manually, then Django won't create the automatic\nobjects = models.Manager() manager for you. Also note that certain\nparts of Django -- namely, the Django admin site and generic views --\nuse whichever manager is defined first in the model, so if you want\nyour admin site to have access to all objects (not just site-specific\nones), put objects = models.Manager() in your model, before you\ndefine CurrentSiteManager.
Jika anda sering menggunakan pola ini:
\nfrom django.contrib.sites.models import Site\n\ndef my_view(request):\n site = Site.objects.get_current()\n ...\nthere is simple way to avoid repetitions. Add\ndjango.contrib.sites.middleware.CurrentSiteMiddleware to\nMIDDLEWARE. The middleware sets the site attribute on every\nrequest object, so you can use request.site to get the current site.
Although it's not required that you use the sites framework, it's strongly\nencouraged, because Django takes advantage of it in a few places. Even if your\nDjango installation is powering only a single site, you should take the two\nseconds to create the site object with your domain and name, and point\nto its ID in your SITE_ID setting.
Ini adalah bagaimana Django menggunakan kerangka situs:
\nIn the redirects framework, each\nredirect object is associated with a particular site. When Django searches\nfor a redirect, it takes into account the current site.
Dalam flatpages framework, setiap flatpage dihubungkan dengan situs tertentu. Ketika sebuah flatpage dibuat, anda menentukan Site nya, dan FlatpageFallbackMiddleware memeriksa situs saat ini dalam mengambil flatpage untuk dimunculkan.
In the syndication framework, the\ntemplates for title and description automatically have access to a\nvariable {{ site }}, which is the\nSite object representing the current\nsite. Also, the hook for providing item URLs will use the domain from\nthe current Site object if you don't\nspecify a fully-qualified domain.
In the authentication framework,\ndjango.contrib.auth.views.LoginView passes the current\nSite name to the template as\n{{ site_name }}.
The shortcut view (django.contrib.contenttypes.views.shortcut)\nuses the domain of the current\nSite object when calculating\nan object's URL.
In the admin framework, the "view on site" link uses the current\nSite to work out the domain for the\nsite that it will redirect to.
RequestSiteLink to this heading#Some django.contrib applications take advantage of\nthe sites framework but are architected in a way that doesn't require the\nsites framework to be installed in your database. (Some people don't want to,\nor just aren't able to install the extra database table that the sites\nframework requires.) For those cases, the framework provides a\ndjango.contrib.sites.requests.RequestSite class, which can be used as\na fallback when the database-backed sites framework is not available.
A class that shares the primary interface of\nSite (i.e., it has\ndomain and name attributes) but gets its data from a Django\nHttpRequest object rather than from a database.
Setel atribut name dan domain ke nilai dari get_host().
Sebuah obyek RequestSite mempunyai antarmuka mirip pada obyek Site biasa, kecuali metode __init__() nya mengambil sebuah obyek HttpRequest. Itu dapat menyimpulkan domain dan name dengan mencari domain permintaan. Itu mempunyai metode save() dan delete() untuk mencocokkan antarmuka dari Site, tetapi metode-metode memunculkan NotImplementedError.
get_current_siteLink to this heading#Akhirnya, untuk menghindari kode fallback berulang, kerangka kerja menyediakan sebuah fungsi django.contrib.sites.shortcuts.get_current_site()
Sebuah fungsi yang memeriksa jika django.contrib.sites dipasang dan mengembalikan salah satu obyek Site object saat ini atau obyek RequestSite berdasarkan pada permintaan. Itu mencari situs saat ini berdasarkan pada request.get_host() jika pengaturan SITE_ID tidak ditentukan.
Both a domain and a port may be returned by request.get_host() when the Host header has a port\nexplicitly specified, e.g. example.com:80. In such cases, if the\nlookup fails because the host does not match a record in the database,\nthe port is stripped and the lookup is retried with the domain part\nonly. This does not apply to\nRequestSite which will always\nuse the unmodified host.