Django Sites Framework初始设置 [英] Django Sites Framework initial setup

问题描述

我对相当一维的Django实现感到满意，但现在正在尝试了解多站点共享内容的过程。

我已经阅读了Django Sites框架和许多关于该主题的帖子，但是我没有得到如何启动使用相同的第二个网站的基础知识数据库，但将其自身显示为单独的域名。

我有一个非常快乐和本本的django网站，包含一个项目中运行的一个应用程序。 / p>

要使用教程的说明，我开始了一个项目mysite与

  django-admin.py startproject mysite 
  

然后开始一个应用程序 p>

  manage.py startapp polls 
  

Q1：网站框架是否假定每个网站是单独的项目或单独的应用程序？

项目中的第二个应用程序polls2似乎是有意义的，但是在定义SITE_ID的settings.py中，似乎是一个完整的项目。有应用程序设置的方法吗？

与mysite相邻的第二个项目mysite2会给我一个具有自己设置的第二个结构。 py和一个单独的SITE_ID，但是似乎很大程度上违反了干原则，因为我将复制相邻姐妹项目的许多元素。

Q2：听起来我需要将数据库模型（models.py）重新定义为多对多关系，以便在站点之间共享数据。这是否只是改变了Django访问这些表格的方式，还是现有网站的数据库也需要重新构建？

您对于实现网站的预期流程的指导框架将是非常好的，非常感谢。

解决方案

Q1：站点框架假设每个站点一个单独的项目或
a单独的应用程序？

Django网站通常由多个应用程序组成，因此单一应用程序不会真的工作但是，对于每个网站的单独项目来说，这是没有帮助的。

每个站点都有一个单独的设置文件是违规的的DRY原则？不必要。您可以（并且应该）创建具有常用设置的基本设置文件。然后，您可以将它们导入到每个站点设置文件中。

例如，在您的项目目录中，您可以有三个设置文件：

  base_settings.py 
 siteA_settings.py 
 siteB_settings.py 
  

siteA_settings.py 和 siteB_settings.py 将导入所有设置， code> base_settings.py 。

唯一认为你必须放入每个网站设置文件是具有单个站点ID的 SITE_ID 设置。所有其他设置可能会在整个网站（ base_settings.py ）中共享，或者是特定于某个网站（ siteA_settings.py ， siteB_settings.py ）取决于您的个人需求。例如，您可以重新定义每个站点设置中的 TEMPLATE_DIRS 设置，如果您有单独的每个站点模板，但是如果模板在您没有的网站上共享至。与所有其他设置相同 - url结构，安装的应用程序列表等。

然后，您可以通过指定设置文件来选择要运行的站点。例如，使用Django开发服务器：

  python manage.py runserver --settings = mysite.siteA_settings 
  

或

  python manage .py runserver --settings = mysite.siteB_settings 
  





---

Q2：听起来像我需要将数据库模型（models.py）重新定义为
a多对多关系，用于在站点之间共享数据。那个
只是改变了Django访问这些表格的方式，还是现有的
网站的数据库也需要重建？

站点之间共享的模型不需要修改，只要所有对象都是共享的。只有当您想要控制模型的哪个对象出现在哪个站点的情况下，您需要通过从模型中添加一个关系（多对多或外键，具体取决于您的需要） Django的网站模型。

这样做确实会改变底层数据库结构（因为添加外键需要额外的列中的给定模型的数据库表，并添加多对多关系需要一个完整的附加表）。网站框架本身也使用自己的数据库表，所以你需要在启用它后同步数据库。

添加关系后，您可以轻松地将查询限制在对象旨在用于当前网站 - 例如使用 CurrentSiteManager 。另一方面，您仍然可以访问所有对象，使用默认管理器（即通常访问ORM的 Model.objects 形式）。

I'm comfortable with fairly one-dimensional Django implementations, but now trying to understand the multi-sites-with-shared-stuff process.

I've read through the Django Sites Framework and many posts on the topic, but I'm not getting the basics of how to start a second site that uses the same database, but presents itself as at a separate domain name.

I have a very happy and by-the-book django site consisting of one app running in a project.

To use the parlance of the tutorials I began a project "mysite" with

django-admin.py startproject mysite

and then started an app "polls" with

manage.py startapp polls

Q1: Does the Sites Framework assume each site is a separate project or a separate app?

A second app 'polls2' within the project seems to make sense, but the settings.py where SITE_ID is defined seems to be a whole-project thing. Is there a means to make app-by-app settings?

A second proj 'mysite2' adjacent to 'mysite' would give me a second structure with its own settings.py and a separate SITE_ID, but then there seems a big violation of the "DRY" principle as I'd be duplicating many elements of the adjacent sister project.

Q2: Sounds like I'll need to redefine database models (models.py) into a many-to-many relationships for sharing data between sites. Does that just change the way Django accesses those tables, or will the existing site's database need to be rebuilt as well?

Your guidance on what the intended process for implementing the sites framework would be great and much appreciated.

解决方案

Q1: Does the Sites Framework assume each site is a separate project or a separate app?

A Django website usually consists of multiple apps, so the "single app" approach wouldn't really work. But it's not helpful to think in terms of a separate project for every site either. The only thing that have to be separate for every site is the settings file.

Does having a separate settings file for every site is a violation of the DRY principle? Not necessarily. You can (and should) create a base settings file with common settings. You would then import them in per-site settings files.

For example in your project directory you could have three settings files:

base_settings.py
siteA_settings.py
siteB_settings.py

siteA_settings.py and siteB_settings.py would import all the settings from base_settings.py.

The only think you have to put in the per-site setting files is the SITE_ID setting with an individual site id. All the other settings may be shared across the sites (base_settings.py) or be specific to a particular site (siteA_settings.py, siteB_settings.py) depending on your individual needs. For example you can redefine the TEMPLATE_DIRS setting in per-site settings, if you have seperate per-sites templates, but if the templates are shared across the sites you don't have to. The same with all the other settings - url structure, list of installed apps, etc.

You would then choose which site you want to run just by specifying the settings files. For example with the Django development server:

python manage.py runserver --settings=mysite.siteA_settings

or

python manage.py runserver --settings=mysite.siteB_settings

---

Q2: Sounds like I'll need to redefine database models (models.py) into a many-to-many relationships for sharing data between sites. Does that just change the way Django accesses those tables, or will the existing site's database need to be rebuilt as well?

Models that are just shared between the sites don't need to be modified, as long as all the objects are shared. Only in cases when you want to be able to control which object of the model appears on which site, you need to account for that by adding a relationship (Many To Many or a Foreign Key, depending on your needs) from your model to the Django's Site model.

Doing that does indeed change the underlying database structure (as adding a Foreign Key requires an additional column in a database table for a given model, and adding a Many To Many relationship requires a whole additional table). The Sites framework itself also uses its own database table, so you need to sync the database after enabling it.

After you add the relationship you can easily restrict your query to objects intended for the current site - for example by using the CurrentSiteManager. On the other hand you still can access all the objects, using the default manager (i.e. the usual Model.objects form of accessing the ORM).

这篇关于Django Sites Framework初始设置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！