Twoja pierwsza strona w Django: Witaj, świecie

Jak przystało na książkę informatyczną, rozpoczniemy przygodę od utworzenia strony z tekstem "Witaj, świecie!".

Gdybyśmy chcieli utworzyć taką stronę bez stosowania frameworka, po prostu umieścilibyśmy tekst "Witaj, świecie!" w pliku tekstowym, nazwalibyśmy plik hello.html i umieścilibyśmy go na serwerze WWW. Zauważ, że w tym procesie określiliśmy dwa bardzo istotne elementy tworzonej strony WWW: jej zawartość (tekst "Witaj, świecie!") i jej adres URL (http://www.example.com/hello.html lub http://www.example.com/files/hello.html, gdyby umieścić plik w podfolderze).

W Django również trzeba określić obie informacje, ale czyni się to w inny sposób. Zawartość strony tworzy funkcja widoku natomiast adres URL określa system URLconf. Najpierw napiszmy funkcję widoku wyświetlającą tekst "Witaj, świecie!".

from django.http import HttpResponse

def hello(request):
    return HttpResponse("Witaj, świecie!")

from django.conf.urls.defaults import *

# Uncomment the next two lines to enable the admin:
# from django.contrib import admin
# admin.autodiscover()

urlpatterns = patterns('',
    # Example:
    # (r'^mysite/', include('mysite.foo.urls')),

    # Uncomment the admin/doc line below and add 'django.contrib.admindocs'
    # to INSTALLED_APPS to enable admin documentation:
    # (r'^admin/doc/', include('django.contrib.admindocs.urls')),

    # Uncomment the next line to enable the admin:
    # (r'^admin/(.*)', admin.site.root),
)

from django.conf.urls.defaults import *

urlpatterns = patterns('',
)

from django.conf.urls.defaults import *
from mysite.views import hello

urlpatterns = patterns('',
    ('^hello/$', hello),
)

>>> import sys
>>> print sys.path

Jak Django przetwarza żądanie?

Zanim przejdziemy do drugiej funkcji widoku, zatrzymajmy się na chwilę i wyjaśnijmy podstawowy sposób działania Django. W szczególności opiszmy, jak to się dzieje, że po odwiedzeniu adresu http://127.0.0.1:8000/hello/ w przeglądarce internetowej, otrzymaliśmy tekst "Witaj, świecie!".

Wszystko zaczyna się od pliku ustawień. Po uruchomieniu polecenia python manage.py runserver, skrypt poszukuje pliku nazwanego settings.py w tym samym folderze co manage.py. Plik zawiera różnego rodzaju ustawienia dla tego konkretnego projektu Django, wszystkie zapisane dużymi literami: TEMPLATE_DIRS, DATABASE_NAME itp. Najważniejszym ustawieniem jest prawdopodobnie ROOT_URLCONF. Wartość ta informuje Django, który moduł Pythona powinien być stosowany jako główna konfiguracja adresów URL dla tej witryny.

Przypomnij sobie, że polecenie django-admin.py startproject utworzyło pliki settings.py i urls.py? Automatycznie wygenerowany plik settings.py zawiera wartość ROOT_URLCONF wskazującą na automatycznie wygenerowany plik urls.py. Otwórz plik settings.py i obacz to na własne oczy:

ROOT_URLCONF = 'mysite.urls'

Odpowiada to plikowi mysite/urls.py.

Gdy przesyłamy żądanie pobrania zawartości konkretnego adresu URL — na przykład żądania dla /hello/ — Django wczytuje plik URLconf wskazywany przez ustawienie ROOT_URLCONF. Następnie sprawdza wszystkie zawarte tam wzorce w podanej kolejności, porównując za każdym razem adres URL z podanym wzorcem aż do momentu odnalezienia dopasowania. Gdy znajdzie dopasowanie, wywołuje powiązaną z nim funkcję widoku, przekazując obiekt HttpRequest jako pierwszy parametr. (Wkrótce dokładniej omówimy szczegóły obiektu HttpRequest).

Jak pokazaliśmy w pierwszej funkcji widoku, musi ona zwrócić obiekt HttpResponse. Gdy to uczyni, Django zajmie się resztą, konwertując obiekt Pythona na odpowiednią odpowiedź serwera z odpowiednimi nagłówkami HTTP oraz treścią (czyli zawartością strony WWW).

Podsumowując:

1. Przychodzi żądanie dotyczące /hello/.
2. Django określa główny plik URLconf, analizując zawartość zmiennej ROOT_URLCONF.
3. Django przegląda wszystkie wzorce URL z pliku URLconf w poszukiwaniu pierwszego pasującego do /hello/.
4. Jeśli znajdzie dopasowanie, wywołuje powiązaną z nim funkcję widoku.
5. Funkcja widoku zwraca HttpResponse.
6. Django konwertuje HttpResponse na odpowiednią odpowiedź HTTP zawierająca stronę WWW.

Teraz wiesz już, jak tworzyć strony WWW za pomocą Django. Nie jest to trudne: wystarczy napisać funkcje widoków i odwzorowania adresów na otworzone funkcje w pliku URLconf.

Drugi widok — dynamiczna zawartość

Przykładowy widok "Witaj, świecie!" stanowił dobrą podstawę do pokazania sposobu działania Django, ale nie był przykładem dynamicznej strony WWW, ponieważ zwracana zawartość zawsze była identyczna. Za każdym razem, gdy odwiedzisz stronę /hello/ zobaczysz dokładnie ten same tekst, jakby to była zwykła, statyczna strona HTML.

Jako drugi widok utwórzmy coś bardziej dynamicznego — stronę WWW wyświetlającą aktualną godzinę i czas. To kolejny bardzo prosty krok, gdyż nie wymaga bazy danych lub informacji od użytkownika — po prostu zwrócimy wewnętrzną godzinę serwera. Choć sama użyteczność przykładu jest niewiele większa od "Witaj, świecie!", zapewni wprowadzenie kilku nowych elementów.

Widok wymaga dwóch rzeczy: obliczenia aktualnej daty i czasu oraz zwrócenia HttpResponse zawierającego te informacje. Jeśli masz doświadczenie z językiem Python, wiesz, że język ten zawiera moduł datetime do obliczania dat. Oto jak z niego skorzystać:

>>> import datetime
>>> now = datetime.datetime.now()
>>> now
datetime.datetime(2008, 12, 13, 14, 9, 39, 2731)
>>> print now
2008-12-13 14:09:39.002731

Użycie jest bardzo proste i nie ma nic wspólnego z Django. To zwykły kod Pythona. (Chcemy byś wiedział dokładnie, gdzie kod to zwykły Python, a gdzie dodatki wprowadzane przez Django. Poznając Django, będziesz mógł część wiedzy zaaplikować do innych projektów Pythona, które niekoniecznie stosują Django).

Aby utworzyć widok Django, który wyświetla aktualną datę i czas, wystarczy dołączyć do widoku wywołanie datetime.datetime.now(), a następnie zwrócić obiekt HttpResponse. Oto wynik tej operacji:

from django.http import HttpResponse
import datetime

def current_datetime(request):
    now = datetime.datetime.now()
    html = "<html><body>Teraz jest %s.</body></html>" % now
    return HttpResponse(html)

Podobnie jak wcześniejsza funkcja widoku, także ta powinna znaleźć sięw pliku views.py. Zauważ, że w tym przykładzie z racji przejrzystości pominęliśmy funkcję hello, ale w rzeczywistości plik views.py będzie miał następująca zawartość:

from django.http import HttpResponse
import datetime

def hello(request):
    return HttpResponse("Hello world")

def current_datetime(request):
    now = datetime.datetime.now()
    html = "<html><body>Teraz jest %s.</body></html>" % now
    return HttpResponse(html)

(Od tej pory w kolejnych przykładach nie będziemy umieszczać prezentowanych wcześniej fragmentów kodu, chyba że okaże się to niezbędne. Z kontekstu łatwo będzie można wywnioskować, czy dany fragment jest nowy, czy stary).

Prześledźmy zmiany wprowadzone w views.py prowadzące do powstania widoku current_datetime.

• Dodaliśmy na początku pliku import modułu datetime, by móc obliczać daty.

• Nowa funkcja current_datetime wylicza aktualną datę i czas jako obiekt datetime.datetime i zapamiętuje ją w zmiennej lokalnej.

• Drugi wiersz kodu widoku tworzy odpowiedź HTML, wykorzystując tekst ze znacznikami formatowania. Element %s w tekście to specjalna konstrukcja tymczasowa powodująca wstawienie w jej miejscu zawartości zmiennej tekstowej. Zmienna now to tak naprawdę obiekt obiekt typu datetime.datetime, a nie tekst, ale %s wymusza konwersję dowolnego obiektu do jego reprezentacji tekstowej, która będzie miała postać "2008-12-13 14:09:39.002731". W wyniku powstanie tekst o zawartości "<html><body>It is now 2008-12-13 14:09:39.002731.</body></html>".

  (Tak, zaprezentowany kod HTML nie jest poprawny, ale staramy się, by przykład był krótki i prosty).

• Na końcu widok zwraca obiekt HttpResponse zawierający wygenerowaną odpowiedź — podobnie jak to miało miejsce w funkcji widoku hello.

Po dodaniu kodu do views.py, musimy jeszcze dodać wzorzec do pliku urls.py, by poinformować Django o adresie URL, dla którego ma wywołać widok. Użyjmy adresu w postaci /time/:

from django.conf.urls.defaults import *
from mysite.views import hello, current_datetime

urlpatterns = patterns('',
    ('^hello/$', hello),
    ('^time/$', current_datetime),
)

Dokonaliśmy w tym miejscu dwóch zmian. Po pierwsze, zaimportowaliśmy funkcję current_datetime. Po drugie i ważniejsze, dodaliśmy odwzorowanie adresu URL na nowy widok. Proste, prawda?

Po napisaniu widoku i uaktualnieniu URLconf, uruchom serwer i odwiedź adres http://127.0.0.1:8000/time/ w swojej przeglądarce. Powinieneś zobaczyć aktualną datę i czas.

Pliki URLconf i luźne powiązanie komponentów

Nadszedł właściwy czas, by przyjrzeć się dokładniej kluczowej filozofii kryjącej się za URLconf i Django jako takim: zasadzie luźnego powiązania komponentów. Mówiąc krótko, luźne powiązanie komponentów to technika tworzenia oprogramowania, która ceni sobie łatwość wymiany poszczególnych komponentów. Jeśli dwa komponenty są luźno powiązane, zmiana w jednym z nich będzie miała niewielki lub żaden wpływ na pozostałe elementy.

Pliki URLconf z Django to dobry, praktyczny przykład tej zasady. W aplikacji Django, definicje adresów URL i wywoływane przez nie funkcje widoków są luźno powiązane; decyzja co do adresu URL wybranej funkcji i sama funkcja znajdują się w dwóch różnych miejscach. Pozwala to zmienić jeden z elementów bez wpływania na drugi.

Przyjrzyjmy się widokowi current_datetime. Gdybyśmy chcieli zmienić adres URL tego elementu aplikacji — np. z /time/ na /current-time/ — wystarczyłoby wprowadzić modyfikację w pliku URLconf bez martwienia się o funkcję widoku. Podobnie, gdybyśmy chcieli zmienić funkcję widoku — zmodyfikować jej logikę lub przenieść do innego modułu — możemy to zrobić bez wpływania na adres URL, do którego funkcja przynależy.

Co więcej, gdybyśmy chcieli udostępnić tę samą funkcjonalność związaną z datą pod kilkoma różnymi adresami URL, moglibyśmy to zrobić edytując plik URLconf bez jakichkolwiek zmian w kodzie widoku. W poniższym przykładzie funkcja current_datetime jest dostępna pod dwoma różnymi adresami URL. To bardzo uproszczony przykład, ale sama technika bywa ogromnie pomocna:

urlpatterns = patterns('',
    ('^hello/$', hello),
    ('^time/$', current_datetime),
    ('^another-time-page/$', current_datetime),
)

Luźne powiązanie widoków i adresów URL pokazaliśmy na praktycznym przykładzie. Inne przykłady tej bardzo istotnej filozofii pojawią się w dalszych rozdziałach książki.

Trzeci widok — dynamiczny adres URL

W widoku current_datetime zawartość strony — aktualna data i czas — były dynamiczne, ale same adres URL (/time/) pozostawał statyczny. W większości dynamicznych aplikacji WWW, adres URL zawiera parametry wpływające na wynik działania strony. Przykładowo internetowy sklep z książkami może każdej książce przypisać własny adres URL, na przykład /books/243/ lub /books/81196/.

Utwórzmy trzeci widok, który będzie wyświetlał aktualną datę i czas przesuniętą o określoną liczbę godzin. Naszym celem jest stworzenie strony, która po użyciu adresu /time/1/ wyświetli czas o jedną godzinę w przyszłość, dla adresu /time/2/ wyświetli czas o dwie godziny w przyszłość, dla /time/3/ trzy godziny w przyszłość itd.

Nowicjusz mógłby zechcieć utworzyć osobną funkcję widoku dla każdego przesunięcia, co spowodowałoby powstanie konfiguracji URL o następującej treści:

urlpatterns = patterns('',
    (r'^time/$', current_datetime),
    (r'^time/plus/1/$', one_hour_ahead),
    (r'^time/plus/2/$', two_hours_ahead),
    (r'^time/plus/3/$', three_hours_ahead),
    (r'^time/plus/4//$', four_hours_ahead),
)

Oczywiście ten kod ma poważne wady. Nie tylko doprowadziłby do powielenia funkcji widoków, ale również sama aplikacja byłaby mocno ograniczona ze względu na obsługę tylko kilku predefiniowanych przesunięć godziny. Gdybyśmy w przyszłości zechcieli utworzyć stronę, która wyświetla przesunięcie o pięć godzin w przyszłość, musielibyśmy utworzyć osobny widok i wpis w URLconf, jeszcze bardziej pogłębiając duplikację kodu. Potrzebujemy abstrakcyjnego rozwiązania.

W jaki sposób zaprojektować aplikację, by używała dowolnych przesunięć godzinowych? Kluczem okazuje się użycie znaków wieloznacznych we wzorcu adresu URL. Jak wspomnieliśmy wcześniej, wzorzec jest wyrażeniem regularnym, więc wystarczy, że zastosujemy element \d+, by dopasować się do jednej lub większej liczb cyfr:

urlpatterns = patterns('',
    # ...
    (r'^time/plus/\d+/$', hours_ahead),
    # ...
)

(Używamy konstrukcji # ..., by wskazać, że mogą istnieć inne wzorce nie przedstawione w tym przykładzie).

Nowy wzorzec dopasuje się do dowolnego adresu URL o strukturze /time/plus/2/, /time/plus/25/ a nawet /time/plus/100000000000/. Ograniczmy więc maksymalne przesunięcie do 99 godzin. Oznacza to, że będziemy dopuszczać wprowadzenie jednej lub dwóch cyfr, więc fragment wyrażenia regularnego przekształcimy w \d{1,2}:

(r'^time/plus/\d{1,2}/$', hours_ahead),

Po określeniu elementu wieloznacznego w adresie URL, musimy w jakiś sposób przekazać tę informację do funkcji widoku, by móc wykorzystać jedną funkcję do obsługi dowolnych przesunięć godziny. Zadanie to wykonamy, umieszczając nawiasy okrągłe wokół danych we wzorcu adresu. W tym konkretnym przypadku jako dane do przekazania do funkcji chcemy potraktować część wieloznaczną adresu, więc otocz nawiasami fragment \d{1,2}:

(r'^time/plus/(\d{1,2})/$', hours_ahead),

Jeśli używałeś wcześniej wyrażeń regularnych, z pewnością znasz znaczenie nawiasów okrągłych: stosuje się je do zapamiętania danych z dopasowanego tekstu.

Końcowa wersja URLconf wraz z dwoma poprzednimi widokami wygląda następująco:

from django.conf.urls.defaults import *
from mysite.views import hello, current_datetime, hours_ahead

urlpatterns = patterns('',
    ('^hello/$', hello),
    ('^time/$', current_datetime),
    (r'^time/plus/(\d{1,2})/$', hours_ahead),
)

Po zakończeniu tematu adresów, możemy przejść do tworzenia widoku hours_ahead.

Funkcja hours_ahead jest bardzo podobna do napisanej wcześniej funkcji current_datetime z jedną istotną różnicą: przyjmuje dodatkowy argument, liczbę godzin przesunięcia. Oto kod widoku:

def hours_ahead(request, offset):
    offset = int(offset)
    dt = datetime.datetime.now() + datetime.timedelta(hours=offset)
    html = "<html><body>Za %s godzin(y) będzie %s.</body></html>" % (offset, dt)
    return HttpResponse(html)

Przeanalizujmy kod wiersz po wierszu:

• Funkcja widoku hours_ahead przyjmuje dwa parametry: żądanie i przesunięcie.

  • Parametr request (żądanie) jest obiektem HttpRequest, podobnie jak w funkcjach hello i current_datetime. Powtórzmy to raz jeszcze: każdy widok zawsze pobiera obiekt HttpRequest jako swój pierwszy parametr.

  • Parametr offset (przesunięcie) jest wartością tekstową pobraną przez nawiasy z wzorca adresu. Jeśli adres URL miał postać /time/plus/3/, parametr offset będzie zawierał tekst '3'. Jeśli adres URL miał postać /time/plus/21/, parametr offset będzie zawierał tekst '21'. Pamiętaj, że pobrane z adresu wartości zawsze będą tekstami, a nie liczbami, nawet jeśli składają się z samych cyfr jak '21'.

    Nadaliśmy zmiennej nazwę offset, ale możesz jej nadać dowolną nazwę, o ile jest poprawnym identyfikatorem Pythona. Nazwa zmiennej nie ma znaczenia; istotne jest tylko to, że stanowi drugi parametr funkcji tuż za żądaniem. (Można również w URLconf określać parametry kluczowe zamiast pozycyjnych, ale więcej informacji na ten temat pojawi się dopiero w rozdziale 8.).

• Pierwszym krokiem wykonywanym w funkcji jest wywołanie int() na parametrze offset. Powoduje to konwersję tekstu na liczbę.

  Pamiętaj, że Python zgłosi wyjątek ValueError, jeśli wywołamy int() na wartości, której nie można skonwertować na wartość całkowitą, na przykład tekstu 'foo'. W prezentowanym przykładzie nie musimy się o to martwić, ponieważ możemy być pewni, że parametr offset będzie tekstem zawierającym tylko i wyłącznie cyfry. Wiemy to, gdyż tak napisaliśmy wyrażenie regularne (\d{1,2}), by przyjmowało tylko liczby. To jedna z interesujących cech URLconf — zapewniają one prosty, ale skuteczny system walidacji danych wejściowych.

• W następnym wierszu wyliczamy aktualną datę i czas oraz dodajemy do wyniku odpowiednią liczbę godzin. Funkcję datetime.datetime.now() wykorzystaliśmy już w widoku current_datetime. Nowym elementem jest arytmetyka dotycząca dat wykonywana za pomocą obiektu datetime.timedelta dodawanego do obiektu datetime.datetime. Wynik zostaje zapamiętany w zmiennej dt.

  Ten wiersz pokazuje również, dlaczego wywołaliśmy int() dla parametru offset — funkcja datetime.timedelta wymaga, by parametr hours był liczbą całkowitą.

• Następnie konstruujemy wynikowy kod HTML, podobnie jak we wcześniejszym widoku current_datetime. Mała różnica polega na tym, że tym razem przekazujemy do systemu formatującego dwie wartości, a nie tylko jedną. Z tego powodu pojawiają się dwa symbole zastąpienia i krotka z wartościami do wstawienia: (offset, dt).

• Na końcu zwracamy obiekt HttpResponse zawierający kod HTML. To fragment, który dobrze znamy.

Po napisaniu funkcji widoku i URLconf, uruchom serwer deweloperski Django (jeśli jeszcze nie został uruchomiony) i odwiedź adres http://127.0.0.1:8000/time/plus/3/, by przekonać się czy działa. Następnie odwiedź adresy http://127.0.0.1:8000/time/plus/5/ i http://127.0.0.1:8000/time/plus/24/. Na końcu sprawdź adres http://127.0.0.1:8000/time/plus/100/, by upewnić się, że adres obsługuje tylko jedno lub dwucyfrowe wartości przesunięcia. W ostatnim przypadku Django powinien zgłosić błąd o nieodnalezieniu strony, podobny do tego opisywanego w notce o błędach 404. Adres URL http://127.0.0.1:8000/time/plus/ (bez podania przesunięcia) również zgłosi błąd 404.

Ładne strony błędów Django

Popodziwiaj przez chwilę tę wspaniałą aplikację, która udało się nam napisać... bo za chwilę ją zepsujemy! Celowo wprowadźmy błąd w pliku views.py, tworząc z wiersza offset = int(offset) widoku hours_ahead komentarz:

def hours_ahead(request, offset):
    #offset = int(offset)
    dt = datetime.datetime.now() + datetime.timedelta(hours=offset)
    html = "<html><body>Za %s godzin(y) będzie %s.</body></html>" % (offset, dt)
    return HttpResponse(html)

Uruchom serwer deweloperski i przejdź do adresu /time/plus/3/. Pojawi się strona błędu z mnóstwem informacji, włącznie z komunikatem o błędzie TypeError umieszczonym na samym początku strony: "unsupported type for timedelta hours component: str".

Co się stało? A więc, funkcja datetime.timedelta oczekuje, że parametr hours będzie liczbą całkowitą, a my zamieniliśmy kod dokonujący takiej konwersji na komentarz. Z tego powodu datetime.timedelta zgłosiło błąd. To rodzaj błędu, który wcześniej czy później pojawia się u każdego programisty.

Celem tego przykładu było zaprezentowanie stron błędu Django. Dokładnie przeanalizuj stronę, by poznać wszystkie udostępniane przez nią informacje.

Zwróć uwagę na kilka interesujących elementów:

• Na górze strony pojawiają się kluczowe informacje o wyjątku: jego rodzaj, parametry związane z wyjątkiem (najczęściej komunikat dokładniej opisujący zdarzenie), plik oraz numer wiersza, w którym wystąpił wyjątek.

• Poniżej podstawowych informacji strona wyświetla pełną informacje o stosie Pythona w momencie wystąpienia wyjątku. Przypomina to standardowe informacje o stosie z interpretera Pythona, ale w trybie interaktywnym. Dla każdego poziomu na stosie Django wyświetla nazwę pliku, nazwę funkcji/metody, numer wiesza i kod źródłowy danego wiersza.

  Kliknij wiersz z kodem źródłowym (w kolorze ciemnoszarym), a pojawi się kilka wierszy przed i po wierszu z błędem, zapewniając odpowiedni kontekst.

  Kliknij element "Local vars" poniżej dowolnej ramki stosu, aby zobaczyć tablicę ze wszystkimi zmiennymi lokalnymi i ich wartościami z momentu wystąpienia wyjątku. Taka informacja znacząco pomaga w odnalezieniu źródła błędu.

• Zauważ tekst "Switch to copy-and-paste view" poniżej nagłówka "Traceback". Kliknij te słowa, a stos zamienia się na alternatywną wersję, którą można łatwo kopiować i wklejać. Użyj tej informacji, jeśli chcesz poinformować o wyjątku inne osoby, by uzyskać pomoc — na przykład poprosić o radę osoby na kanale IRC Django lub na liście dyskusyjnej Django.

  Znajdujący się niżej przycisk "Share this traceback on a public Web site" automatycznie, za pomocą jednego kliknięcia, prześle cały stos wywołań do http://www.dpaste.com/, gdzie otrzymasz unikatowy adres URL ułatwiający współdzielenie danych z innymi.

• Następny dział nazwany "Request information" zawiera sporo informacji o żądaniu WWW, które spowodowało pojawienie się błędu: dane GET oraz POST, wartości ciasteczek i dane meta takie jak nagłówki CGI. Dodatek H zawiera opis wszystkich informacji znajdujących się w obiekcie żądania.

  Jeszcze niżej znajduje się dział "Settings" zawierający wszystkie ustawienia danej instalacji Django. (Wspomnieliśmy wcześniej o ustawieniu ROOT_URLCONF, a w dalszej części książki przedstawimy ich znacznie więcej). Wszystkie dostępne opcje są szczegółowo opisane w dodatku E).

Strony błędów są w stanie wyświetlić dodatkowe informacje w niektórych szczególnych sytuacjach, na przykład jeśli wystąpi błąd składniowy szablony. Zagadnieniem tym zajmiemy się w momencie omawiania systemu szablonów Django. Na razie usuń znak komentarza z wiersza offset = int(offset), by funkcja widoku znowu działała prawidłowo.

Czy jesteś programistą, który lubi szukać błędów za pomocą odpowiednio umieszczonych instrukcji print? Możesz w tym celu wykorzystać strony błędów Django, ale bez instrukcji print. W dowolnym miejscu widoku tymczasowo umieść polecenie assert False, by wymusić wyświetlenie strony błędu. Następnie możesz przejrzeć zmienne lokalne i stan programu. Oto przykład używający widoku hours_ahead:

def hours_ahead(request, offset):
    offset = int(offset)
    dt = datetime.datetime.now() + datetime.timedelta(hours=offset)
    assert False
    html = "<html><body>Za %s godzin(y) będzie %s.</body></html>" % (offset, dt)
    return HttpResponse(html)

Warto pamiętać, że większość prezentowanych informacji jest bardzo ważna — pojawiają się fragmenty kodu Pythona oraz konfiguracji Django. Byłoby wielką nierozwagą pokazywanie takich informacji publicznie. Nieprzyjazna osoba mogłaby wykorzystać te dane do poznania sposobu działania witryny i zaatakowania jej. Z tego powodu opisywane strony błędów wyświetlane są tylko w trybie testowania projektu Django. Wkrótce wyjaśnimy, jak wyłączyć tryb testowy. Na razie pamiętaj, że każdy nowy projekt znajduje się domyślnie w trybie testowym. (Brzmi znajomo? Opisywane wcześniej strony błędów działają w podobny sposób).

Co dalej?

Do tej pory tworzyliśmy funkcje widoków z zakodowanym na stałe w Pythonie kodem HTML. Ułatwiało to zaprezentowanie pierwszych przykładów, ale w rzeczywistych aplikacjach to bardzo rzadko jest słuszne rozwiązanie.

Django zawiera prosty, ale bardzo użyteczny system szablonów, który umożliwia separację projektu strony od kodu. System szablonów omówimy w następnym rozdziale.