MerixGames

2 czerwca 2016

/ code & tools

Django Project Template - tworzenie struktury projektu (cz. 1)

Paweł Hały

W tym artykule dowiesz się jak rozpocząć pracę z Django 1.8 i utworzyć strukturę projektu, która będzie czytelna dla Ciebie jak i innych programistów. W przedstawianym projekcje będę wykorzystywać język Python w wersji 3.4. Nasza backendową przygodę rozpoczniemy od przygotowania środowiska pod projekt, a zakończymy ją na dobrych wzorcach i omówieniu kilku gotowych rozwiązań.

Przedstawione w moim artykule przykłady nie stanowią doskonałego wzorca, lecz są jedynie wskazówkami tego, jak poprawnie tworzyć strukturę projektu. Będzie ona tworzyć logiczną całość i pozwoli intuicyjnie poruszać się po strukturze folderów i plików.

Przygotowanie środowiska

Na samym początku musisz zastanowić się jak pracować z projektem aby zachować porządek w systemie i uniknąć konfliktu między projektami. Niezależnie to od tego, czy  Django jest już na twoim komputerze, czy dopiero planujesz przystąpić do jego instalacji. Sytuacja komplikuje się jednak gdy zachodzi potrzeba pracy z Django o niższej lub wyższej wersji niż nasze wcześniej utworzone i przechowywane na dysku projekty. Oczywiście, póki nie korzystasz z dodatkowych modułów, możesz bez problemu przeinstalowywać Django do wymaganej wersji. Podobnie możesz zrobić też z Pythonem. Jednakże, aby ominąć ten problem, możesz skorzystać z wirtualnego środowiska zwanego virtualenv. Jego zadaniem jest wyizolowanie konkretnej wersji Pythona, Django oraz innych rozszerzeń w taki sposób, by nie wpływały na inne projekty o dowolnych konfiguracjach. Można to porównać do szafki, do której wkładasz wszystkie niezbędne rzeczy i izolujesz od reszty. Takich “szafek” możesz posiadać nieskończenie wiele i otwierać ich zawartość w dowolnej chwili.  Tym samym zachowasz wymagane ustawienia dla każdego projektu.

Virtualenv możesz zainstalować zgodnie z instrukcją na jego oficjalnej stronie internetowej. Następnym krokiem po instalacji paczki będzie stworzenie pierwszego wydzielonego na nasz projekt środowiska. W tym celu należy przejść do konsoli, udać się do interesującego nas folderu (gdzie  utworzony zostanie podfolder mający identyczną nazwę jak nasze środowisko wirtualne)  i wykonać polecenie:

virtualenv --python=python3.4 myenv

myenv jest nazwą naszego środowiska wirtualnego, która będzie indywidualna dla każdego projektu. W celu uruchomienia i aktywowania nowego środowiska należy wykonać następujące polecenie:

source myenv/bin/activate

Zauważ, że został utworzony folder o takiej samej nazwie  jak nasz wirtualne środowisko.

Jeżeli wszystko wykonało się  poprawnie, w konsoli pojawi się następujący w nawiasach prefix:

(myenv) ~/projectname$

Ciągłe wpisywanie ścieżki aktywacji virtualenv jest mało efektywne i możliwe do zoptymalizowania dzięki dodatkowi virtualenvwrapper. Możesz doinstalować go stosując się do instrukcji na stronie dokumentacji.Do jego poprawnej pracy potrzebny jest virtualenv.

Teraz możemy utworzyć środowisko wirtualne wykonując poniższe polecenie (zasada działania jest taka sama jak w przypadku virtualenv, lecz tym razem wykorzystujemy wrapper

mkvirtualenv --python=/usr/bin/python3 myenv

Jeżeli napotkasz błąd podczas wykonywania powyższego polecenia, użyj innej nazwy środowiska wirtualnego (np. myenv_project). Przyczyną błędu jest już istniejące środowisko wirtualne o takiej samej nazwie. 

W tym przypadku nie musimy przechodzić do katalogu (gdzie będziemy tworzyć projekt i uruchamiać virtualenv) aby wygenerować odpowiedni zestaw plików konfiguracji środowiska wirtualnego. Pliki te są grupowane w wcześniej wskazanym folderze podczas instalacji dodatku. Nie musimy już aktywować środowiska za pomocą ścieżki, lecz jedynie poprzez  wykonanie polecenia:

workon myenv

Podobnie jak w przypadku virtualenv, w konsoli zostanie dodany prefix.

Teraz w naszym nowym środowisku musimy zainstalować interesującą nas wersję Django.

Przegląd domyślnej struktury projektu

Jeżeli pierwszy raz masz styczność z Django, musisz zapoznać się z podstawową strukturą projektu. Django umożliwia wygenerowanie niezbędnych elementów katalogu za pomocą poniższego polecenia ( wykonaj je w katalogu, w którym chcesz tworzyć stronę):

django-admin startproject mysite

mysite jest dowolną nazwą katalogu w którym zostaną utworzone niezbędne podkatalogi i pliki.

W skutek powyższego polecenia otrzymasz następującą strukturę projektu:

mysite/
    manage.py
    mysite/
        __init__.py
        settings.py
        urls.py
        wsgi.py

Jeżeli nie chcesz tworzyć dodatkowego katalogu o nazwie „mysite”, możesz dodać kropkę na końcu polecenia:

django-admin startproject mysite .

Kropka na końcu linii spowoduje, że cała struktura projektu zostanie zbudowana w katalogu, w którym się lokalnie znajdujemy (nie zostanie utworzony dodatkowy katalog). Oznacza to, że nasz projekt będzie wyglądał następująco:

your_folder/
    manage.py
    mysite/
        __init__.py
        settings.py
        urls.py
        wsgi.py

Wynika to z tego, że nazwa głównego folderu nie ma znaczenia dla Django i może przyjmować dowolna wartość. Jednak musisz zwrócić uwagę na nazwę folderu „mysite”. To tutaj są przechowywane wszystkie podstawowe ustawienia umożliwiające poprawne wystartowanie strony. Przyjrzyjmy się każdemu elementowi z osobna:

  1. __init__.py – z reguły jest to pusty plik, który sygnalizuje, że folder jest pakietem. W starszych wersjach Pythona plik ten umożliwia importowanie zawartości pozostałych plików znajdujących się w tym katalogu. Więcej na ten temat opisano na oficjalnej stronie tego języka;
  2. settings.py – jest plikiem, który zawiera wszystkie ustawienia projektu umożliwiające uruchomienie strony i konfigurację np. bazy danych;
  3. urls.py – tutaj umieszczone są wszystkie wzorce adresów strony, przez które możemy odwoływać się do poszczególnych podstron projektu,
  4. wsgi.py – w tym miejscu znajdują się wszystkie ustawienia dotyczące WSGI, które mogą nas interesować gdy będziemy instalować stronę na zewnętrznym serwerze.

Istnieje jeszcze bardzo ważny,  plik manage.py. Jest on odpowiedzialny za wykonywanie poleceń, które przewidzieli twórcy Django. Dzięki niemu możesz wchodzić w interakcję z elementami projektu za pomocą linii poleceń.

Modyfikacja ustawień pliku settings.py

Jeżeli odwiedzisz plik settings.py zobaczysz, że wszystkie najważniejsze elementy zostały wypisane i przygotowane tak, abyśmy mogli szybko je zmodyfikować. Na początek warto zmienić strefę czasową, w moim przypadku będzie to:

TIME_ZONE = 'Europe/Berlin'

Następnie, jeżeli zachodzi taka potrzeba, możesz zmodyfikować ustawienia bazy danych lub pozostawić domyśle wartości:

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
}
}

Dodatkowo musisz wskazać Django pod jakim adresem mają być listowane pliki statyczne i w jakim folderze w projekcie maja być one przeszukiwane. Możesz to zrobić wprowadzając następujące ustawienia:

STATIC_URL = '/static/' 
STATIC_ROOT = os.path.join(BASE_DIR, 'static')

Warto też, abyś przyjrzał się krotce o nazwie INSTALLED_APPS. W niej wypisujemy wszystkie nazwy aplikacji, których będziemy używać w projekcie. Ważne jest, aby po każdej nazwie wprowadzonej w postaci tekstowej (np. “my_app”,) dodać na końcu przecinek. Więcej na temat tworzenia własnych aplikacji zostanie przedstawione w dalszej części artykułu.

Teraz tylko musisz utworzyć niezbędne tabele w bazie danych. Możesz to zrobić za pomocą polecenia:

python manage.py migrate

Tak przygotowany projekt jest w pełni funkcjonalną strukturą umożliwiającą lokalne uruchomienie projektu.

Struktura aplikacji

Może się wydawać, że to już wszystko co potrafi Django w dziedzinie generowania projektu. Okazuje się jednak, że istnieje jeszcze jeden element o którym nie wspomnieliśmy wcześniej – są to aplikacje. Aplikacje to dodatkowe foldery o dowolnej nazwie, wydzielające projekt na mniejsze elementy. Dzięki temu twoja praca będzie przejrzysta i czytelna dla każdego programisty. Nie będziesz musiał przeszukiwać wielo-linijkowych plików, aby odnaleźć interesującą cię funkcjonalność. To właśnie w aplikacjach będziesz spędzać najwięcej czasu i w nich stworzysz interesującą cię funkcjonalność. Dodatkowo Django wychodzi developerom naprzeciw i tworzy taką strukturę za pomocą polecenia:

python manage.py startapp myapps

myapps jest nazwą naszej aplikacji – tą nazwę należy dodać do INSTALLED_APPS

Powyższe polecenie wygeneruje nam następującą strukturę:

mysite/
    manage.py
    mysite/
        __init__.py
        settings.py
        urls.py
        wsgi.py
 
    myapps/
        migrations/
                __init__.py
        __init__.py
        admin.py
        models.py
        tests.py
        views.py

Przyjrzyjmy się teraz każdemu z plików:

  1. __init__.py – podobnie jak opisałem go  wcześniej – tu nic się nie zmienia;
  2. admin.py – w tym pliku możemy konfigurować panel administratora tak, aby można było łatwo zarządzać bazą danych i zawartością strony;
  3. models.py – w tym miejscu wprowadzamy kod, który pozwoli utworzyć tabele w bazie danych poprzez wykorzystanie schematów przygotowanych na potrzeby frameworka (ORM - mapowanie obiektowo-relacyjne). Oznacza to że za pomocą języka Python możemy manipulować strukturą bazy danych bez znajomości SQL;
  4. tests.py – tutaj możemy tworzyć oprogramowanie testujące naszą aplikację,
  5. views.py – tutaj tworzymy warstwę interfejsu użytkownika w myśl założeń MVC.

Dobrą praktyką jest także utworzenie dodatkowego pliku formsy.py, który należy umieścić w naszej aplikacji. W tym pliku będą przechowywane wszystkie formularze aplikacji.

Każda aplikacja prawdopodobnie będzie zawierała w przyszłości pliki z szablonami (np, HTML), które należy umieszczać w folderze „templates” wewnątrz aplikacji. Może to wyglądać następująco:

mysite/
    manage.py
    mysite/
        __init__.py
        settings.py
        urls.py
        wsgi.py
    myapps/
        templates/
            myapps/
               any.html
        migrations/
                __init__.py
        __init__.py
        admin.py
        models.py
        tests.py
        views.py

Jeżeli jesteś wnikliwym czytelnikiem, to zauważysz, że dodałem jeszcze dodatkowy folder o nazwie aplikacji i dopiero w nim umieściłem plik z rozszerzeniem HTML. Taki układ jest kwestią umowną, lecz pozwala zachować porządek w projekcie.
Warto także utworzyć folder o nazwie “templates”, który będzie dostępny w całym obszarze projektu. W nim należy przechowywać  szablony HTML, które mogą być obsługiwane przez więcej aplikacji. Wyglądać to będzie następująco:

mysite/
    manage.py
    mysite/
        __init__.py
        settings.py
        urls.py
        wsgi.py
    myapps/
        templates/
            myapps/
                any.html
        migrations/
                __init__.py
        __init__.py
        admin.py
        models.py
        tests.py
        views.py
    templates/

Może się jednak okazać, że Django nie widzi naszych szablonów. Problem ten można rozwiązać poprzez uzupełnienie listy TEMPLATES znajdującej się w settings.py:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [os.path.join(BASE_DIR, 'templates')],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

Warto zapamiętać, że dla Django nie ma znaczenia to, jakie szablony mają rozszerzenie html,haml czy txt. Warto jednak zachowywać to rozszerzenie, które poprawnie opisuje zawartość pliku.

Co dalej?

Może się wydawać, że w zasadzie zrobiliśmy wszystko co możliwe, aby nasz projekt był czytelny i funkcjonalny. Owszem, stworzona struktura jest użyteczna i zrozumiała. Niestety z czasem zauważysz, że wielokrotne tworzenie tego samego schematu projektu staje się nudne i nieefektywne. To, co omówiłem w tej częsci artykułu, jest przydatne na początku prac z Django i pomaga w jego zrozumieniu. Powinniśmy jednak  pójść o krok dalej i skorzystać z gotowych struktur/'templatek' projektu - tym właśnie zajmiemy się w 2 części artykułu, która ukaże się niebawem. Śledźcie nas na Facebooku, Twitterze i LinkedInie, dzięki czemu na pewno go nie przegapicie!

Strona używa plików cookies. Wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.