Kilka wydań temu zaprezentowaliśmy framework Ruby On Rails. Trudno się dziwić jego popularności wśród wielu webdeveloperów. Jego zalety są bowiem oczywiste – pozwala łatwo i szybko tworzyć nawet bardzo rozbudowane aplikacje internetowe. Okazuje się jednak, że RoR ma silną konkurencję. I to nie tylko w postaci omawianego w tym numerze Zend Framework, ale także frameworków stworzonych w Pythonie. Wśród tych ostatnich prym wiedzie Django.
W poprzednim numerze przybliżyliśmy język Python – w pełni obiektowy, zwięzły i za sprawą licznych bibliotek szeroko dostosowany do zastosowań internetowych. Wszystko po to, aby teraz przejść do omówienia jednego z frameworków napisanych w tym języku.
Bo choć ciężko odmówić Ruby On Rails licznych zalet, to nawet jego sympatycy muszą przyznać, że inne technologie nie pozostają w tyle. O ile licznie pojawiające się frameworki w PHP wciąż są dość młode, a te stworzone w oparciu o Javę wymagają specyficznego środowiska systemowego, to dla programistów Pythona od dawna dostępna jest ciekawa alternatywa w postaci frameworków Django oraz Pylons.
W niniejszym artykule postanowiliśmy skoncentrować się na pierwszym z nich. Django jest łatwiejsze w nauce od Pylons i pozwala szybciej tworzyć proste aplikacje, choć przy bardziej złożonych projektach może nieco ograniczać.
W żadnym razie jednak artykuł ten nie ma za zadanie przekonywać o wyższości Django nad Ruby On Rails lub odwrotnie. Trzeba przyznać, że źródła fenomenu tego drugiego leżą w tworzącym i wspierającym go środowisku programistów. O RoR dużo słychać na konferencjach, wydawanych jest wiele książek jemu poświęconych (w Polsce nie wydano dotąd żadnej na temat Django), także w internecie łatwiej znaleźć dokumentację i poradniki, jak również uzyskać pomoc na specjalistycznych forach internetowych. Programistów RoR jest po prostu więcej.
RoR ma także przewagę w postaci większej ilości wbudowanych mechanizmów oraz dodatków o większej funkcjonalności. Wynika to z faktu, że filozofia Django wymaga utrzymywania frameworka w zwartych ryzach i wykorzystywania jedynie własnych, natywnych rozwiązań. Rozszerzeń powstaje więc mniej, często nie są też one aż tak funkcjonalne. Może mieć to duże znaczenie przy bardziej złożonych projektach.
Wydawać by się mogło, że są to argumenty w zasadzie deklasujące Django w porównaniu z Ruby On Rails. Czy słusznie? W rzeczywistości ważne jest dobranie właściwego rozwiązania do potrzeb. Są bowiem kwestie, które w Django zostały rozwiązane bardzo dobrze, a w wielu przypadkach także jego mniejsza złożoność może przemawiać na korzyść tego systemu.
Ogromną zaletą Django jest jego prostota, dostępność widoków generycznych (które jeszcze bardziej przyspieszają tworzenie aplikacji) oraz samoistnie tworzący się panel administracyjny. To ostatnie sprawia, że Django wydaje się być świetnym rozwiązaniem dla wszelkiego rodzaju systemów zarządzania zawartością (serwisy informacyjne, blogi, sklepy internetowe).
Wydajność frameworków
Istnieje jeszcze jeden bardzo potężny argument przemawiający na korzyść Django. Ruby On Rails jest frameworkiem bardzo zasobożernym, co istotnie wpływa na koszty tworzonych w nim projektów. Sytuację pogarsza dodatkowo fakt, iż RoR wymaga korzystania ze specyficznych serwerów aplikacji, które na dodatek same w sobie nie są zoptymalizowane pod kątem wydajnościowym.
Wystarczy wspomnieć, że aktualnie najbardziej polecany przez środowisko RoR serwer aplikacji – Mongrel – nie posiada nawet wsparcia dla wielowątkowości. Wymusza to tworzenie kilku procesów dla każdego większego projektu, w przeciwnym razie kolejne połączenie z serwerem musiałoby oczekiwać na zakończenie poprzedniego zapytania – co byłoby wyraźnie odczuwalne dla użytkowników.
Jeśli dodać do tego fakt, że pojedynczy proces dedykowany określonemu projektowi nie zajmuje mniej niż 40 MB pamięci RAM (często dużo więcej), a procesy takie muszą być tworzone praktycznie niezależnie dla każdego uruchomionego projektu to otrzymujemy wyobrażenie o niemałych obciążeniach systemowych takiego rozwiązania. Nie lepiej jest zresztą także ze zużyciem czasu procesora aplikacji korzystających z RoR.
W przypadku Django sprawa wygląda inaczej. Wprawdzie sam framework również jest aplikacją dosyć złożoną (bez porównania bardziej niż prosty skrypt PHP wywołujący kilka zapytań do bazy danych), jednak korzysta on już z bardziej standardowych rozwiązań systemowych – istnieją wdrożenia Django opierające się o FastCGI czy nawet wbudowany moduł serwera Apache.
Pod względem środowiska, hostowanie Django jest więc analogiczne do przygotowania rozwiązania pod PHP. Dodatkowo jeden dedykowany Django proces może obsługiwać wiele projektów równocześnie. Jedynym ograniczeniem jest konieczność separowanie użytkowników systemu (dwaj użytkownicy hostingu współdzielonego nie mogą korzystać z tego samego procesu ze względów bezpieczeństwa).
Wszystko to sprawia, że hosting Django jest mniej skomplikowany od analogicznej usługi przeznaczonej dla Ruby On Rails. Jeśli przyrównać Django do niektórych bardziej złożonych aplikacji PHP, może się również okazać, że atut wydajności będzie po stronie Django. Framework ten narzuca bowiem programiście konieczność trzymania się dobrych praktyk programistycznych, podczas gdy skrypty PHP są często pisane w nie najlepszym stylu.
W teorii Django ze względu na łatwiejszą i mniej kłopotliwą konfigurację powinien być również bardziej powszechny wśród dostawców hostingu niż ma się to w przypadku RoR. Praktyka jest jednak nieco inna. Ze względu na niskie zainteresowanie ze strony programistów, nie ma na polskim rynku wielu providerów oferujących wsparcie dla Django, a ci którzy są – obsługują również RoR.
Organizacja projektów Django
Django jest frameworkiem stworzonym wokół wzorca MVC (Model-View-Controller), który zakłada odseparowanie od siebie trzech warstw: danych, logiki biznesowej oraz prezentacji. O samym MVC i jego zaletach wielokrotnie pisaliśmy na łamach Internet Makera. Dlatego nasi czytelnicy dobrze wiedzą, że taki sposób projektowania aplikacji ma wiele zalet.
W rzeczywistości w Django stosowana jest terminologia różniąca się od MVC, choć skupiona wokół tej samej idei. Django operuje na wzorcu Model-View-Template. Model odpowiada za obsługę struktur danych (w tym ich mapowanie w systemie bazodanowym), widok (ang. view) to miejsce tworzenia właściwej logiki biznesowej – zachowania aplikacji, podczas gdy wbudowany system szablonów (ang. template) pozwala zadbać o właściwą prezentację informacji wyprodukowanych przez widok.
Nadrzędną zasadą Django – podobnie jak wielu innych frameworków – jest zasada DRY, czyli Don’t Repeat Yourself. Zgodnie z tą regułą konieczne działania dokonuje się tylko w jednym, najwłaściwszym do tego miejscu, by później po prostu korzystać z wykonanej wcześniej pracy.
Zaletą korzystania z frameworków jest również narzucenie określonego porządku w kodzie. Każdy element aplikacji posiada swoje ściśle określone miejsce. Nadrzędną jednostką organizacyjną w Django jest projekt – gdy wydasz polecenie tworzące nowy projekt, zostanie utworzony katalog wraz z podstawową strukturą plików projektu. Na poziomie projektu obsługiwane są w szczególności połączenia z bazą danych i inne ogólne elementy konfiguracyjne. Warto w tym miejscu zaznaczyć, że Django potrafi komunikować się jedynie z jedną bazą danych w ramach pojedynczego projektu (do wyboru MySQL, PostgreSQL, Microsoft SQL oraz SQLite).
Projekt jest jednak tylko pewną ramą dla systemu, który zamierzasz stworzyć. W nim samym nie jest definiowana żadna konkretna funkcjonalność. Jest to domeną tzw. aplikacji (wyodrębnioną fizycznie jako podkatalog w folderze projektu). Aplikacja powinna całościowo odpowiadać za realizację narzuconych jej celów, korzystając z właściwych sobie modeli danych i widoków. Powinna być autonomiczna funkcjonalnie. W ramach projektu można umieszczać wiele aplikacji, podobnie jak poprawnie stworzoną aplikację powinieneś móc w dowolnym momencie przenieść do innego projektu i w nim użyć.
Jak to wygląda w praktyce? W artykule pokazujemy w jaki sposób możesz stworzyć prosty system blogowy. Projektem jest więc blog. Podstawowa aplikacja odpowiada za gromadzenie i wyświetlanie jego zawartości – wpisów na blogu (notek), wraz z informacjami uzupełniającymi. Aplikacja odpowiada także za szeregowanie publikacji na blogu, na przykład według miesiąca publikacji oraz kategorii – w celu łatwiejszego przeglądania. Dodatkowo mógłbyś ją rozszerzyć na przykład o wyszukiwarkę.
Istnieje możliwość dołączenia do projektu bloga kolejnych aplikacji, na przykład sondy internetowej. Taka sonda funkcjonalnie koncentruje się wokół magazynowania, przetwarzania i prezentacji pytań i udzielanych na nie odpowiedzi. Stanowi więc system nie będący w bezpośredniej zależności od bloga (opisując sprawę obrazowo, w dowolnym momencie masz możliwość „wyjęcia” sondy z bloga i wstawienia jej do innego projektu).
W praktyce pożądane jest niekiedy, aby aplikacje nie były idealnie niezależne. Bywa, że istnieje potrzeba by nieco się one zazębiały pomiędzy sobą – sonda może na przykład pobierać informacje o numerze ID notki na blogu, do której jest dołączona.
Ważne jednak, aby w takim przypadku taka integracja była jak najbardziej przejrzysta i skalowalna. Jeśli przeniesiesz sondę z bloga do systemu CMS, to powinna wystarczyć jedynie prosta podmiana ID notki na np. ID określonej wiadomości w aktualnościach na nowej stronie, żeby aplikacja ta zaczęła poprawnie funkcjonować.
Krok drugi: Stwórz aplikację bloga
1. Zdefiniuj modele danych
Prace nad blogiem rozpoczniemy od zdefiniowania modelu danych, czyli wzorca danych stosowanego w twojej aplikacji i zapisanego w bazie. Utworzymy model notki na blogu oraz jej przyporządkowania do kategorii. W tym celu w folderze aplikacji {stala}showblog{/stala} wyedytuj plik {stala}models.py{/stala} – służy on właśnie do opisywania modeli. Wprowadź modele zgodnie z ilustracją. Pamiętaj o tym, że Python bardzo rygorystycznie przestrzega zgodności wcięć w kodzie.
2. Dodaj aplikację do ustawień
Nie wystarczy jedynie utworzenie aplikacji w projekcie, by stała się ona aktywna. Należy jeszcze dodać ją do zainstalowanych aplikacji. W tym celu przejdź ponownie do pliku {stala}settings.py{/stala} i na jego końcu dopisz do {stala}INSTALLED_APS{/stala} pozycję {stala}blog.showblog{/stala}. Uzupełnij także listę {stala}TEMPLATE_CONTEXT_PROCESSORS{/stala} – co przyda się później.
3. Zsynchronizuj dane
Zanim omówimy stworzony model, przeprowadź jego synchronizację z bazą danych. Służy do tego specjalna operacja syncdb dostarczona wraz z narzędziami Django. Aby ją uruchomić, przejdź do katalogu głównego projektu i wydaj polecenie .{stala}/manage.py syncdb{/stala}. Przy pierwszym uruchomieniu tej opcji zostaniesz poproszony dodatkowo o podanie danych koniecznych do stworzenia konta administratora projektu.
4. Szczegóły modelu
W bazie utworzone zostały struktury danych, zgodne z opisem w modelu. Stworzony został model kategorii, który zawiera pole ID – klucz główny z autoinkrementacją oraz nazwę. Notki zawierają ID, tytuł, krótki opis (skrót), dłuższy opis, status widoczności oraz datę publikacji. Kategoria i autor są kluczami obcymi – pierwszy do stworzonego uprzednio modelu, drugi do modelu frameworka User (użytkownicy panelu administracyjnego).
5. Ustal wzorce adresu URL
Kolejnym krokiem jest precyzyjne ustawienie wzorców adresu. Musisz poinformować Django, że strona główna będzie dostępna w głównej ścieżce adresu URL, poszczególne notki na blogu będą mieć postać /{ID}/ (np. /36/), natomiast wzorzec dla listowania postów według miesiąca to /2008/03/. Wzorce mogą być dowolne, określasz je używając wyrażeń regularnych w pliku urls.py. Wpisz dane z ilustracji. Wzorcami dla listy kategorii zajmiemy się nieco później.
6. Użyj widoków generycznych
Szczegółowe objaśnienie zasady działania urls.py oraz widoków generycznych znajdziesz w artykule. Uzupełnij swój plik urls.py o definicję trzech słowników, przechowujących dane konfiguracyjne dla widoków generycznych – archive_info, index_info oraz note_info. Dodatkowo zaimportowaliśmy obiekt Note z aplikacji showblog. Dzięki gotowym do użycia widokom generycznym możesz dużo szybciej budować swoją aplikację.
7. Znajdź szablon dla bloga
Czas przystąpić do tworzenia szablonów bloga. W tym celu znajdź w internecie gotowe szablony HTML lub stwórz własny od podstaw. Tworząc przykładowego boga skorzystaliśmy z darmowego szablonu pochodzącego z serwisu http://www.freecsstemplates.org. Przed przystąpieniem do kolejnego kroku utwórz katalog {stala}templates{/stala} w głównej stronie projektu, a w nim katalog {stala}showblog{/stala} – tam wgrywać będziesz pliki HTML. Grafikę skopiuj do katalogu {stala}MEDIA_URL{/stala} ustawionego w {stala}settings.py{/stala}.
8. Przystosuj szablon strony głównej
Django oferuje dość uniwersalny system szablonów, do którego przekazywane są dane pochodzące z kontrolera. Można je przetwarzać za pomocą makroinstrukcji. Widoki generyczne przekazują dane o ustandaryzowanym nazewnictwie (np. object_list). Jeśli zwrócona została lista, wystarczy ją przejrzeć pętlą for i wstawić odpowiednie wartości – jak w przykładzie (plik zapisz jako index.html). Nagłówek oraz stopkę możesz wyłączyć do osobnych plików.
9. Przystosuj szablon notki
Czas na przygotowanie szablonu notki z bloga. Tym razem nie musisz stosować już pętli for – do szablonu przekazywane są dane konkretnej wiadomości na blogu. Są one widoczne pod postacią predefiniowanej nazwy object. Wystarczy, że w odpowiednich miejscach wstawisz znaczniki odwołujące się do poszczególnych pól modelu danych. Na koniec stwórz również szablon month.html (lista archiwum miesięcznego) oraz category.html (przyda się później). Mogą być one identyczne jak szablon index.html.
10. Przekaż własne dane do szablonu
Aby wyświetlić listę miesięcy będziesz musiał przekazać do szablonu własne dane. Jest to możliwe dzięki mechanizmowi „context processors”. W folderze aplikacji {stala}showblog{/stala} utwórz plik {stala}context_processor.py{/stala} z zawartością zgodną z ilustracją. Są to dwie metody zwracające potrzebne dane w postaci słownika. Metoda {stala}GetAllCategories(){/stala} przyda się później. Aby dostęp do wyniku był możliwy z poziomu szablonów, należy dołączyć funkcję procesora kontekstu do projektu poprzez {stala}settings.py{/stala} (co uczyniliśmy już w punkcie 2).
11. Stwórz szablon prawego menu
Do strony głównej dołączony został (include) szablon side.html. Przygotuj go zgodnie ze wzorcem z ilustracji. Wykorzystywane są tutaj globalne wartości przekazane przez „context processor” – listy, które możesz przeglądać i wyświetlać korzystając z instrukcji for. Zastosowane została również użyta jedna funkcja formutująca, dostępna spośród licznych zaimplementowanych w mechaniźmie Django – date.
12. Aplikacja już działa
Gratulacje, twoja aplikacja posiada już pewną funkcjonalność. Po dodaniu przykładowych informacji za pośrednictwem panelu administracyjnego, blog będzie wyglądać tak jak na ilustracji.
Django natywnie używa kodowania UTF8. Choć możesz chcieć używać kodowania ISO-8859-2, lepiej twórz swoje strony już w oparciu o Unicode. Będziesz do tego potrzebował edytora, który potrafi zapisywać dokumenty w tym kodowaniu lub odpowiedniego konwertera.
Krok trzeci: Wyczaruj panel administracyjny
1. Dodaj ściężkę URL dla panelu
Django potrafi automatycznie wygenerować panel administracyjny do tworzonej treści.
Zaraz sam przekonasz się, w jak prosty sposób się to odbywa. Zacznijmy od zaprojektowania ścieżki adresu URL dla panelu. Zakładamy, że panel będzie dostępny po wpisaniu ścieżki {stala}/admin/{/stala}. Poddaj edycji plik urls.py i wprowadź w nim jedną krótką linię.
2. Dodaj panel do aplikacji
Aby panel administracyjny mógł zostać obsłużony przez Django, należy go dodać do zainstalowanych aplikacji w projekcie. W tym celu przejdź do pliku settings.py, a następnie do listy {stala}INSTALLED_APPS{/stala} dopisz wartość {stala}django.contrib.admin{/stala}. Po tej operacji konieczna będzie synchronizacja projektu z bazą danych. W tym celu wydaj polecenie {stala}./manage.py syncdb{/stala}. Pamiętaj, aby synchronizować bazę po każdym dodaniu aplikacji.
3. Zaloguj się do panelu
Wpisz w przeglądarce adres http://www.twojastrona.pl/admin/. Powinien wyświetlić się ekran logowania. Jeśli nie widzisz obrazów i stylów, oznacza to, że na serwerze HTTP nie został stworzony właściwy alias do katalogu z zawartością statyczną panelu. Poproś o pomoc administratora swojego serwera. Zaloguj się do panelu, używając swojego loginu oraz hasła wybranego w czasie pierwszej synchronizacji bazy danych.
4. Uruchom dostęp do modelu danych
Aktualnie w panelu administracyjnym masz jedynie możliwość zarządzania jedynie użytkownikami. Dane aplikacji showblog nie są jeszcze dostępne. Aby to zmienić należy wskazać Django, że chcesz uruchomić zarządzanie danymi przez panel. Przejdź do {stala}models.py{/stala} aplikacji {stala}showblog{/stala} i wprowadź w definicji modelu klasę Admin, zgodnie z ilustracją. Słowo kluczowe {stala}pass{/stala} informuje Pythona, że klasa jest pusta.
5. Dostrój widoku modelu
W tej chwili możesz już zarządzać modelem poprzez panel. Warto jednak dostroić domyślne ustawienia. Uzupełnij {stala}models.py{/stala} zgodnie z powyższą ilustracją, aby wprowadzić kilka zmian. Dzięki nim określisz sposób wyświetlania nazw modeli ({stala}verbose_name{/stala}), a także wyświetlanie samego modelu w kontekście skalarnym (istotne przy listowaniu). Dokonasz nawet przeciążenia metody {stala}save{/stala}, aby automatycznie uzupełnić pole daty w nowym wpisie.
6. Zacznij korzystać z panelu
Możesz już wykorzystać panel administracyjny do dodania pierwszych informacji na swojego bloga. Na początek wprowadź dostępne kategorie notek, gdyż będziesz do nich linkować z edycji wpisu (notki). W samym wpisie masz dostępnych kilka wartości. Pola daty nie musisz wypełniać – zostanie ono uzupełnione automatycznie. Dodawane artykuły powinny natychmiast pojawić się na twoim blogu.
Konfiguracja projektu
Wiesz już, w jaki sposób zorganizowany jest projekt. Warto jeszcze poświęcić chwilę przygotowaniu projektu do pracy. Po jego utworzeniu musisz przede wszystkim skonfigurować środowisko za pomocą pliku settings.py. Przykład praktyczny zamieściliśmy na końcu artykułu – krok po kroku tworzymy projekt nowego bloga. W tym miejscu należy jedynie zwrócić uwagę na kilka ustawień, które pominięte zostały w przykładzie praktycznym.
Django potrafi pracować w trybie z włączonym debbugerem. Tryb taki powoduje precyzyjne wyświetlanie informacji o błędach oraz ich źródle w przeglądarce użytkownika. Jest to bardzo przydatne podczas tworzenia aplikacji, ale bezwzględnie powinieneś go wyłączyć po zakończeniu prac nad projektem. Tryb ten może bowiem sprawić, że potencjalni napastnicy dowiedzą się o twojej aplikacji więcej niż powinni. Ponadto zmniejsza on wydajność aplikacji.
Warto również pamiętać, że jeśli uruchamiasz kilka projektów, należy im ustawić odrębne wartości SITE_ID. Ustrzeże cię to przed problemem konfliktu plików cookie z poszczególnych projektów w tej samej domenie. Zaraz po stworzeniu nowego projektu, dołączanych jest do niego kilka standardowo zainstalowanych aplikacji oraz middletów dostarczonych wraz z Django, a wykorzystywanych m.in. w panelu administracyjnym do autoryzacji użytkowników. Mogą ci się one przydać także w tworzonym przez siebie kodzie.
Ciekawym plikiem jest urls.py – umożliwia on sterowanie adresami internetowymi wykorzystywanymi w projekcie. Django przechwytuje wszystkie wywołania URL, zaś plik urls.py służy do ich dopasowania wedle określonych wzorców do określonych aplikacji i zachowań. Funkcjonalnie jest to więc odpowiednik routes.rb z RoR, choć sposób działania urls.py jest inny.
Projektowanie adresów URL odbywa się za pomocą wyrażeń regularnych wraz z podaniem nazwy aplikacji, do której zostanie przekazane zapytanie jeśli wzorzec zostanie dopasowany pomyślnie. Przeanalizujmy następujący przykład:
urlpatterns = patterns('',
# Test
(r'^test/', 'projekt.aplikacja.views.test'),
# Test2
(r'^test2/(.*)', 'projekt.aplikacja.views.test2'),
# Panel administratora
(r'^admin/', include('django.contrib.admin.urls'))
)
Jeśli adres URL rozpoczyna się od {stala}test/{/stala} (w stosunku do względnej ścieżki URL projektu) to zapytanie zostanie przekazane do funkcji test, zdefiniowanej w pliku widoków {stala}views.py{/stala} w ramach aplikacji o nazwie {stala}aplikacja{/stala}, w projekcie o nazwie {stala}projekt{/stala}. W dalszej części artykułu, analizując widoki dowiesz się, w jaki sposób możesz obsłużyć takie zapytanie.
Do widoku przekazywane są również informacje dynamiczne pochodzące z adresu URL. Spójrz na drugi przykład, który przekazuje zapytanie do funkcji {stala}test2{/stala}. W widoku tym będziesz miał możliwość „odebrania” informacji zawartej w nawiasie okrągłym (zgodnie z regułami regexp kropka i gwiazdka oznacza dowolny ciąg znaków). A więc twoja metoda może dostosować swoje zachowanie do otrzymanego parametru.
Wreszcie trzeci przykład pokazuje, w jaki sposób można uzyskać dostęp do panelu administracyjnego (dostarczonego wraz z Django). A także, jak skorzystać z możliwości dołączenia pliku definicji URL. Przy bardziej rozbudowanych aplikacjach dobrze jest utworzyć w ramach aplikacji odrębne pliki urls.py – zwiększa to przejrzystość tego rozwiązania oraz jego skalowalność.
Istnieje ponadto możliwość przekazywania dodatkowych opcji do funkcji poprzez trzeci element listy zdefiniowanej w {stala}urlpatterns{/stala}. Praktyczne zastosowanie poznasz w trakcie tworzenia przykładowego bloga zgodnie z naszymi instrukcjami.
Model danych
Plik definiujący modele danych znajduje się w folderze aplikacji i nosi nazwę {stala}models.py{/stala}. Wewnątrz niego możesz tworzyć klasy odpowiadające poszczególnym modelom. Rodzi się pytanie – czym jest model? Trudno o krótką definicję. Z jednej strony jest to określona, jednolita struktura danych opisująca stan obiektu wraz z jego atrybutami. Przenosząc to na terminologię programowania obiektowego – model jest obiektem, zawierającym atrybuty, ale nie zawierającym metod. Z kolei przekładając model wprost na implementację w strukturach bazodanowych, jest to pojedyncza tabela relacyjnej bazy danych.
Bardzo wygodną cechą Django jest jego wysokopoziomowa obsługa pól w modelu. Dostępne typy danych nie ograniczają się wyłącznie do kilku podstawowych (np. łańcuch, liczba czy data), ale obsługują znacznie więcej typów abstrakcyjnych. Są one na dodatek wygodnie przedstawiane w panelu administracyjnym – na przykład typ daty zostanie uzupełniony o kalendarz, z którego możesz wybrać interesującą cię datę.
Oto przykładowy model, wyjęty z naszej aplikacji blogowej:
from django.db import models
from datetime import datetime
from django.contrib.auth.models import User
class Category(models.Model):
id = models.AutoField(primary_key=True)
name = models.CharField("Kategoria", maxlength=100)
class Note(models.Model):
id = models.AutoField(primary_key=True)
title = models.CharField("Tytuł", maxlength=150)
description = models.TextField("Krótki opis")
text = models.TextField("Treść")
visible = models.BooleanField("Widoczny", default=True)
publish_date = models.DateTimeField("Data publikacji", blank=True, editable=False)
author = models.ForeignKey(User, verbose_name="Autor")
categories = models.ManyToManyField(Category, verbose_name="Kategorie")
Model tworzysz poprzez dodanie odpowiadającej mu klasy (dziedziczącej po models.Model), a następnie poprzez utworzenie atrybutów. Są one obiektami odpowiednich typów danych. W powyższym przykładzie zawarto na przykład obiekty klasy CharField, TextField, BooleanField czy DateTimeFiled.
Są to określone wysokopoziomowe typy, które niezależnie od standardowych typów dostarczanych przez Pythona posiadają zaimplementowany określony rodzaj zachowań oraz przyjmują typowe dla siebie wartości (Django będzie sprawdzać, czy przekazane dane są poprawne). W panelu administracyjnym każdy z takich typów symbolizowany jest w inny sposób. O ile CharField jest jednoliniowym polem tekstowym to TextField stanowi pole wielowierszowe ({html}