Pisanie pierwszej aplikacji Django, część 1.

Nauczmy się na przykładzie.

Z pomocą tego tutoriala przeprowadzimy cię przez stworzenie prostej aplikacji ankietowej.

Będzie się ona składać z dwóch części:

  • Publicznej strony, która pozwala ludziom obejrzeć ankiety i głosować w nich.
  • Panelu administracyjnego, który pozwala ci dodawać, zmieniać i usuwać ankiety.

Będziemy zakładać, że masz już zainstalowane Django. Możesz sprawdzić, czy Django jest zainstalowane i w jakiej wersji uruchamiając następującą komendę w prompcie powłoki (wskazywanym przez prefix $):

$ python -m django --version

Jeśli Django jest zainstalowane, powinieneś zobaczyć wersję swojej instalacji. Jeśli nie jest, dostaniesz błąd „No module named django”.

Ten tutorial jest napisany dla Django 1.11 i Pythona 3.4 lub późniejszych. Jeśli wersja Django się nie zgadza, możesz przełączyć się na swoją wersję Django używając przełącznika wersji w prawym dolnym rogu tej strony, lub możesz zaktualizować Django do najnowszej wersji. Jeśli wciąż używasz Pythona 2.7, będziesz musiał dostosować nieco próbki kodu, według opisu w komentarzach.

Zobacz Jak zainstalować Django, by znaleźć wskazówki jak usunąć stare wersje Django i zainstalować nową.

Gdzie szukać pomocy:

Jeśli masz problemy z przejściem tego tutoriala, prosimy napisz wiadomość do django-users lub wpadnij na #django na irc.freenode.net, aby czatować z innymi użytkownikami Django, który mogą być w stanie udzielić pomocy.

Tworzenie projektu

Jeśli po raz pierwszy korzystasz z Django, będziesz musiał zająć się wstępną konfiguracją. Konkretnie, będziesz potrzebował wygenerować trochę kodu, który stworzy projekt Django – zbiór ustawień dla instacji Django, wliczając konfigurację bazy danych, ustawienia specyficzne dla Django i specyficzne dla aplikacji.

Z linii komend, wejdź cd do katalogu, gdzie chciałbyś przechowywać swój kod, następnie uruchom następującą komendę:

$ django-admin startproject mysite

Stworzy ona katalog mysite w twoim bieżącym katalogu. Jeśli nie zadziałała, zobacz Problemy z uruchomieniem django-admin.

Informacja

Musisz unikać nazywania projektów tak samo jak wbudowane w Pythona albo Django komponenty. W szczególności znaczy to, że powinieneś unikać używania nazw jak django (co wejdzie w konflikt z samym Django) lub test (wejdzie w konflikt z wbudowanym pakietem Pythona).

Gdzie powinien żyć ten kod?

Jeśli w przeszłości używałeś zwykłego starego PHP (bez użycia nowoczesnych frameworków), prawdopodobnie zwykłeś umieszczać kod w głównym katalogu serwera WWW (takim jak /var/www). W Django nie robi się w ten sposób. Nie jest dobrym pomysłem umieszczać jakiegokolwiek z tego kodu Pythona w katalogu głównym serwera WWW, ponieważ stwarza to ryzyko pojawienia się możliwości, aby ktoś był w stanie widzieć twój kod w Internecie. Nie jest to bezpieczne.

Umieść swój kod w jakimś katalogu poza katalogiem głównym, na przykład w /home/mycode.

Spójrzmy co stworzyło startproject:

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

Te pliki to:

  • Zewnętrzny katalog główny mysite/ jest tylko pojemnikiem na twój projekt. Jego nazwa nie ma znaczenia dla Django; możesz zmienić jego nazwę na dowolną, jaką chcesz.
  • manage.py: Narzędzie linii komend, które pozwala ci oddziaływać z tym projektem Django na wiele sposobów. Możesz przeczytać szczegóły na temat manage.py w django-admin and manage.py.
  • Wewnętrzny katalog mysite/ jest właściwym pakietem Pythona dla twojego projektu. Jego nazwa jest nazwą pakietu Pythona, którą musisz używać, aby zaimportować cokolwiek w tym pakiecie (np. mysite.urls).
  • mysite/__init__.py: Pusty plik, który mówi Pythonowi, że ten katalog powinien być uważany za pakiet Pythona. Jeśli jesteś początkujący w Pythonie, przeczytaj więcej o pakietach w oficjalnej dokumentacji Pythona.
  • mysite/settings.py: Ustawienia/konfiguracja dla tego projektu Django. Django settings powie ci wszystko o tym, jak działają ustawienia.
  • mysite/urls.py: Deklaracje URL-i dla tego projektu Django; „spis treści” twojej strony opartej na Django. Możesz przeczytać więcej o URL-ach w URL dispatcher.
  • mysite/wsgi.py: Punkt wejściowy dla serwerów WWW kompatybilnych z WSGI do serwowania twojego projektu. Zobacz How to deploy with WSGI dla większej ilości szczegółów.

Serwer deweloperski

Zweryfikujmy czy twój projekt Django działa. Przejdź do zewnętrzenego katalogu mysite, jeśli jeszcze tego nie zrobiłeś, i uruchom następujące polecenia:

$ python manage.py runserver

Zobaczysz następujące wyjście w linii komend:

Performing system checks...

System check identified no issues (0 silenced).

You have unapplied migrations; your app may not work properly until they are applied.
Run 'python manage.py migrate' to apply them.

grudnia 02, 2017 - 15:50:53
Django version 1.11, using settings 'mysite.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Informacja

Zignoruj na razie ostrzeżenie o niezastosowanych migracjach bazy danych; zajmiemy się bazą danych za chwilę.

Wystartowałeś serwer deweloperski Django, lekki web-serwer napisany w całości w Pythonie. Zawarliśmy go w Django, abyś mógł dewelopować rzeczy błyskawicznie, nie musząc zajmować się konfiguracją produkcyjnego serwera – jak na przykład Apache – dopóki nie będziesz gotowy na produkcję.

Teraz jest dobry moment, by zwrócić na to uwagę: nie używaj tego serwera w czymkolwiek podobnym do produkcyjnego środowiska. Jest on przewidziany tylko do użytku podczas dewelopmentu. (Jesteśmy w świecie tworzenia web-frameworków, nie web-serwerów.)

Kiedy serwer jest już uruchomiony, odwiedź http://127.0.0.1:8000/ w swojej przeglądarce internetowej. Zobaczysz stronę „Welcome to Django”, w przyjemnych jasnoniebieskich pastelowych kolorach. Zadziałało!

Zmiana portu

Domyślnie komenda runserver uruchamia serwer deweloperski na wewnętrznym IP na porcie 8000.

Jeśli chcesz zmienić port serwera, podaj go jako argument w linii komend. Na przykład, to polecenie uruchamia serwer na porcie 8080:

$ python manage.py runserver 8080

Jeśli chcesz zmienić IP serwera, podaj je razem z portem. Na przykład aby nasłuchiwać na wszystkich dostępnych publicznych IP (przydatne, jeśli używasz Vagranta lub chcesz zaprezentować swoją pracę na innych komputerach w sieci), użyj:

$ python manage.py runserver 0:8000

0 jest skrótem od 0.0.0.0. Pełną dokumentację serwera deweloperskiego można znaleźć w dokumentacji runserver.

Automatyczne przeładowywanie runserver

Serwer deweloperski automatycznie przeładowuje kod Pythona dla każdego żądania, wedle potrzeby. Nie musisz restartować serwera, aby zmiany w kodzie miały efekt. Jednakże niektóre działania, jak dodawanie plików, nie powodują restartu, więc będziesz musiał zrestartować serwer w tych przypadkach.

Tworzenie aplikacji Ankiety

Teraz, kiedy twoje środowisko – „projekt” – jest uruchomione, jesteś gotowy zabrać się do pracy.

Każda aplikacjia, którą piszesz w Django, składa się z pakietu Pythona, który realizuję pewną konwencję. Django zawiera narzędzie, które automatycznie generuje podstawową strukturę katalogów aplikacji, abyś mógł skupić się na pisaniu kodu zamiast na tworzeniu katalogów.

Projekty versus aplikacje

Jaka jest różnica pomiędzy projektem a aplikacją? Aplikacja jest aplikacją webową, która coś robi – na przykład system blogowy, baza danych publicznych wpisów lub prosta aplikacja ankietowa. Projekt jest zbiorem konfiguracji i aplikacji dla konkretnej witryny. Projekt może zawierać wiele aplikacji. Aplikacja może być w wielu projektach.

Twoje aplikacje mogą żyć gdziekolwiek na twojej ścieżce Pythona. W tym tutorialu stworzymy aplikację ankietową tuż obok twojego pliku manage.py, aby mogła być zaimportowana jako jego własny moduł najwyższego poziomu, zamiast podmodułu mysite.

Aby stworzyć swoją aplikację, upewnij się, że jesteś w tym samym katalogu co manage.py i wpisz tę komendę:

$ python manage.py startapp polls

Stworzy ona katalog polls, który jest tak rozplanowany:

polls/
    __init__.py
    admin.py
    apps.py
    migrations/
        __init__.py
    models.py
    tests.py
    views.py

Ta struktora katalogów będzie domem dla aplikacji ankietowej.

Napisz swój pierwszy widok

Napiszmy pierwszy widok. Otwórz plik polls/views.py i umieść tam następujący pythonowy kod:

polls/views.py
from django.http import HttpResponse


def index(request):
    return HttpResponse("Hello, world. You're at the polls index.")

To jest najprostszy widok, jaki jest możliwy w Django. Aby go wywołać, potrzebujemy zmapować go na URL – i do tego potrzebujemy URLconf.

Aby stworzyć URLconf w katalogu ankiet, stwórzmy plik o nazwie urls.py. Katalog twojej aplikacji powinien teraz wyglądać tak:

polls/
    __init__.py
    admin.py
    apps.py
    migrations/
        __init__.py
    models.py
    tests.py
    urls.py
    views.py

W pliku polls/urls.py zawrzyj następujący kod:

polls/urls.py
from django.conf.urls import url

from . import views

urlpatterns = [
    url(r'^$', views.index, name='index'),
]

Następnym krokiem jest wskazanie URLconfowi w korzeniu na moduł polls.urls. W mysite/urls.py dodaj import dla django.conf.urls.include i wstaw include() na listę urlpatterns, aby mieć:

mysite/urls.py
from django.conf.urls import include, url
from django.contrib import admin

urlpatterns = [
    url(r'^polls/', include('polls.urls')),
    url(r'^admin/', admin.site.urls),
]

Funkcja include() function pozwala na odniesienia do innych URLconfów. Zwróć uwagę, że wyrażenia regularne dla funkcji include() nie zawierają $ (znaku końca linii) ale ukośnik rozdzielający. Kiedykolwiek Django napotyka include(), odcina tę część URL-a, która została dopasowana do tego punktu i wysyła pozostłą część ciągu znaków do zaincludowanego URLconfa, do dalszego przetworzenia.

Pomysłem leżącym za include() jest ułatwienie podłączania URL-i. Skoro ankiety są w swoim własnym URLconfie (polls/urls.py), mogą być umieszczone pod „/polls/” lub pod „/fun_polls/” lub pod „/content/polls/” lub dowolnym innym początkiem ścieżki i aplikacja wciąż będzie działać.

Kiedy używać include()

Powinieneś używać include() zawsze, gdy uwzględniasz inne wzorce URL. admin.site.urls jest jedynym wyjątkiem od tej reguły.

Nie zgadza się z tym, co widzisz?

Jeśli widzisz include(admin.site.urls) zamiast tylko admin.site.urls, prawdopodobnie używasz wersję Django, która nie jest zgodna z wersją tego tutoriala. Powinieneś przełączyć się albo na starszą wersję tutoriala, albo nowszą wersję Django.

Podłączyłeś właśnie widok index do URLconf. Zweryfikujmy, czy działa. Uruchom następujące polecenie:

$ python manage.py runserver

Przejdź do http://localhost:8000/polls/ w swojej przeglądarce. Powinieneś zobaczyć napis „Hello, world. You’re at the polls index.”, który zdefiniowałeś w widoku index.

Do funkcji url() są przekazane cztery argumenty, dwa wymagane: regex i view oraz dwa opcjonalne: kwargs i name. Warto w tym momencie dowiedzieć się, do czego służą.

Argument url(): regex

Termin „regex” jest powszechnie używaną krótką formą oznaczającą „wyrażenie regularne”, które jest składnią do dopasowywania wzorców w ciągach znaków, lub w tym przypadku, wzorcach URL-i. Django zaczyna od pierwszego wyrażenia regularnego i idzie w dół listy, porównując zażądany URL z wszystkimi wyrażeniami regularnymi aż odnajdzie takie, które pasuje.

Zwróć uwagę, że te wyrażenia regularne nie przeszukują parametrów GET i POST lub nazwy domeny. Na przykład, w żądaniu do https://www.example.com/myapp/, URLconf będzie szukał myapp/. W żądaniu do https://www.example.com/myapp/?page=3, URLconf też będzie szukał myapp/.

Jeśli potrzebujesz pomocy z wyrażeniami regularnymi, zobacz wpis na Wikipedii i dokumentację modułu re. Również fantastyczna jest książka O’Reilly’ego „Mastering Regular Expressions” napisana przez Jeffreya Friedla. Jednakże w praktyce nie musisz być ekspertem od wyrażeń regularnych, bo tak naprawdę potrzebujesz jedynie wiedzieć jak wyłapywać proste wzorce. Tak naprawdę złożone wyrażenia regularne mogą mieć słabą wydajność wyszukiwania, więc prawdopodobnie nie powinieneś polegać na pełnej ich mocy.

Ostatatecznie, uwaga na temat wydajności: te wyrażenia regularne są kompilowane, gdy po raz pierwszy ładowany jest moduł URLconf. Są super-szybkie (tak długo jak same wyrażenia nie są zbyt skomplikowane, tak jak zauważyliśmy wyżej).

Argument url(): view

Kiedy Django znajdzie pasujące wyrażenie regularne, wywołuje podaną funkcję widoku z obiektem HttpRequest jako pierwszym argumentem i dowolnymi „złapanymi” wartościami z wyrażenia regularnego jako pozostałymi argumentami. Jeśli regex używa prostych złapań, wartości są przekazane jako argumenty pozycyjne; jeśli używa nazwanych złapań, wartości są przekazane jako argumenty nazwane. Za chwilę damy tego przykład.

Argument url(): kwargs

Arbitralne argumenty słownikowe mogą być przekazane w słowniku do docelowego widoku. Nie będziemy używać tej funkcjonalności Django w tym tutorialu.

Argument url(): name

Nazwanie twojego URL-a pozwala odwołać się do niego jednoznacznie z każdego miejsca w Django, szczególnie z wnętrza szablonów. Ta potężna cecha pozwala ci na robienie globalnych zmian we wzorcach URL projektu przez zmianę w pojedynczym pliku.

Jeśli czujesz się dobrze z przepływem żądań i odpowiedzi, przeczytaj drugą część tego tutoriala, aby zacząć pracę z bazą danych.

Back to Top