Wstępna konfiguracja Django Sites Framework

Question

Jestem w pełni zadowolony z dość jednowymiarowych implementacji Django, ale teraz próbuję zrozumieć proces z wieloma witrynami i współdzielonymi treściami.

Przeczytałem w witrynie Django Sites Framework i wiele postów na ten temat, ale nie mam podstaw, jak uruchomić drugą witrynę, która korzysta z tej samej bazy danych, ale prezentuje się jako osobna nazwa domeny .

Mam bardzo szczęśliwą i książkową stronę django składającą się z jednej aplikacji uruchomionej w projekcie.

Aby korzystać żargonie tutoriali zacząłem projekt "mysite" ze

django-admin.py startproject mysite 

a następnie rozpoczął aplikację "polls" z

manage.py startapp polls 

Q1: Czy Miejsca ramowego zakładać, że każda strona jest osobnym projektem lub oddzielną aplikacją?

Druga aplikacja "polls2" w ramach projektu wydaje się mieć sens, ale plik settings.py, w którym zdefiniowana jest identyfikacja SITE_ID, wydaje się być sprawą całego projektu. Czy istnieje sposób na dostosowanie ustawień aplikacji?

Drugi proj "mysite2" obok "mysite" dałby mi drugą strukturę z własnymi settings.py i oddzielną SITE_ID, ale wtedy wydaje się, że duże naruszenie zasady "DRY", jak bym był powielając wiele elementów sąsiedniego projektu siostrzanego.

Q2: Wygląda na to, że będę musiał przedefiniować modele bazy danych (models.py) w relacje wiele do wielu w celu udostępniania danych między lokacjami. Czy to po prostu zmienia sposób, w jaki Django uzyskuje dostęp do tych tabel, czy też konieczna jest przebudowa istniejącej bazy danych witryny?

Twoje wskazówki na temat tego, jak zamierzony proces wdrażania ram witryn byłby wspaniały i doceniany.

Answer 1

Pytanie 1: Czy struktura witryn zakłada, że ​​każda witryna jest oddzielnym projektem lub oddzielną aplikacją ?

Witryna Django zwykle składa się z wielu aplikacji, więc podejście "pojedyncza aplikacja" nie działa tak naprawdę. Ale nie jest również pomocne myślenie w kategoriach oddzielnego projektu dla każdej witryny. Jedynym elementem, który musi być oddzielny dla każdej witryny, jest plik ustawień.

Czy posiadanie osobnego pliku ustawień dla każdej witryny jest naruszeniem zasady DRY? Niekoniecznie. Możesz (i powinieneś) utworzyć plik ustawień podstawowych z typowymi ustawieniami. Następnie można zaimportować je do plików ustawień dla każdej witryny.

Na przykład w katalogu projektu można mieć trzy pliki ustawień:

base_settings.py 
siteA_settings.py 
siteB_settings.py 

siteA_settings.py i siteB_settings.py będzie importować wszystkie ustawienia z base_settings.py.

Jedyne, co uważasz, że musisz ustawić na w plikach ustawień każdej witryny, jest ustawienie SITE_ID z indywidualnym identyfikatorem witryny.Wszystkie inne ustawienia mogą być udostępniane w witrynach (base_settings.py) lub być specyficzne dla konkretnej witryny (siteA_settings.py, siteB_settings.py) w zależności od indywidualnych potrzeb. Możesz na przykład przedefiniować ustawienia TEMPLATE_DIRS w ustawieniach poszczególnych witryn, jeśli masz osobne szablony stron internetowych, ale szablony są udostępniane w witrynach, w których nie musisz. To samo z wszystkimi innymi ustawieniami - struktura adresu URL, lista zainstalowanych aplikacji itp.

Następnie należy wybrać stronę, którą chcesz uruchomić, po prostu określając pliki ustawień. Na przykład z serwera rozwoju Django:

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

lub

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

---

Q2: Wygląda na to będę musiał przedefiniować modele baz danych (models.py) do Many to-many relacje do udostępniania danych między lokacjami. Czy ta zmiana polega na zmianie sposobu, w jaki Django uzyskuje dostęp do tych tabel, czy też konieczna jest przebudowa istniejącej bazy danych witryny ?

Modele, które są po prostu współdzielone między lokacjami, nie muszą być modyfikowane, o ile wszystkie obiekty są udostępniane. Tylko w przypadkach, gdy chcesz mieć możliwość kontrolowania, który obiekt modelu pojawia się na której stronie, musisz to uwzględnić, dodając relację (wiele do wielu lub klucz obcy, w zależności od Twoich potrzeb) od modelu do Model Django: Site.

Wykonanie tego rzeczywiście zmienia podstawową strukturę bazy danych (dodanie klucza obcego wymaga dodatkowej kolumny w tabeli bazy danych dla danego modelu, a dodanie relacji Wiele do wielu wymaga całej dodatkowej tabeli). Sama struktura serwisów korzysta również z własnej tabeli bazy danych, dlatego po jej włączeniu należy zsynchronizować bazę danych.

Po dodaniu relacji można z łatwością ograniczyć zapytanie do obiektów przeznaczonych dla bieżącej witryny - na przykład za pomocą the CurrentSiteManager. Z drugiej strony nadal można uzyskać dostęp do wszystkich obiektów, używając domyślnego menedżera (tj. Zwykłej formy dostępu do ORM w postaci Model.objects).