Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00708 007628 13616960 na godz. na dobę w sumie
Python i Django. Programowanie aplikacji webowych - książka
Python i Django. Programowanie aplikacji webowych - książka
Autor: , , Liczba stron: 392
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-2225-2 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> python - programowanie
Porównaj ceny (książka, ebook, audiobook).

Odkryj pełnię niezwykłych możliwości Django i twórz funkcjonalne aplikacje

Django to stworzony w Pythonie, prosty i nowoczesny framework typu open source. Umożliwia on budowanie funkcjonalnych aplikacji webowych bez potrzeby pisania setek wierszy kodu. Został zaprojektowany w ten sposób, aby doskonale działać jako zwarta całość, ale jego składniki są ze sobą na tyle luźno powiązane, że z łatwością można dokonywać zmian, dodawać i aktualizować funkcjonalności. Ten podręcznik pomoże Ci szybko i efektywnie wykorzystać Django w praktyce.

Książka 'Python i Django. Programowanie aplikacji webowych' zawiera opisy podstawowych i bardziej zaawansowanych elementów tego frameworka, a także wiele przykładowych aplikacji, wspartych szczegółowymi wyjaśnieniami dotyczącymi ich budowy. Dzięki temu podręcznikowi dowiesz się, jak wykorzystać elastyczność i szybkość tworzenia aplikacji w Pythonie w celu rozwiązania typowych problemów, które możesz napotkać podczas swojej pracy. Nauczysz się tworzyć formularze, skrypty, własny system zarządzania treścią oraz aplikacje Django zaledwie w kilka minut, a dzięki gotowym projektom poznasz także tajniki zaawansowanego projektowania.

Poznaj i wykorzystaj nowe możliwości programowania aplikacji!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Python i Django. Programowanie aplikacji webowych Autor: Jeff Forcier, Paul Bissex, Wesley Chun T³umaczenie: Krzysztof Rychlicki-Kicior ISBN: 978-83-246-2225-2 Tytu³ orygina³u: Python Web Development with Django (Developer s Library) Format: 170x230, stron: 392 Odkryj pe³niê niezwyk³ych mo¿liwoœci Django i twórz funkcjonalne aplikacje • Jak w kilka minut za³o¿yæ blog? • Jak bez wysi³ku tworzyæ zaawansowane aplikacje? • Jak budowaæ modele i u¿ywaæ ich? Django to stworzony w Pythonie, prosty i nowoczesny framework typu open source. Umo¿liwia on budowanie funkcjonalnych aplikacji webowych bez potrzeby pisania setek wierszy kodu. Zosta³ zaprojektowany w ten sposób, aby doskonale dzia³aæ jako zwarta ca³oœæ, ale jego sk³adniki s¹ ze sob¹ na tyle luŸno powi¹zane, ¿e z ³atwoœci¹ mo¿na dokonywaæ zmian, dodawaæ i aktualizowaæ funkcjonalnoœci. Ten podrêcznik pomo¿e Ci szybko i efektywnie wykorzystaæ Django w praktyce. Ksi¹¿ka „Python i Django. Programowanie aplikacji webowych” zawiera opisy podstawowych i bardziej zaawansowanych elementów tego frameworka, a tak¿e wiele przyk³adowych aplikacji, wspartych szczegó³owymi wyjaœnieniami dotycz¹cymi ich budowy. Dziêki temu podrêcznikowi dowiesz siê, jak wykorzystaæ elastycznoœæ i szybkoœæ tworzenia aplikacji w Pythonie w celu rozwi¹zania typowych problemów, które mo¿esz napotkaæ podczas swojej pracy. Nauczysz siê tworzyæ formularze, skrypty, w³asny system zarz¹dzania treœci¹ oraz aplikacje Django zaledwie w kilka minut, a dziêki gotowym projektom poznasz tak¿e tajniki zaawansowanego projektowania. • Python dla Django • Instrukcje warunkowe • Funkcje i definicje klas • Programowanie zorientowane obiektowo • Tworzenie bloga • Dynamiczne strony internetowe • Django — tworzenie i u¿ywanie modeli • URL, obs³uga http i widoki • Szablony i przetwarzanie formularzy • System zarz¹dzania treœci¹ • Liveblog • Zaawansowane programowanie • Testowanie aplikacji Poznaj i wykorzystaj nowe mo¿liwoœci programowania aplikacji! Spis treści Przedmowa ........................................................................13 Podziękowania ...................................................................19 O autorach ........................................................................21 Wprowadzenie ...................................................................23 27 Część I Zaczynamy! Rozdział 1 Python dla Django ..............................................................29 Umiejętności w Pythonie to umiejętności w Django ..........................29 Zaczynamy. Interaktywny interpreter Pythona ...................................30 Podstawy Pythona .........................................................................32 Komentarze .............................................................................32 Zmienne i przypisania ..............................................................33 Operatory ................................................................................33 Standardowe typy Pythona .............................................................34 Logiczne wartości obiektów ......................................................34 Liczby .....................................................................................35 Operatory arytmetyczne ............................................................36 Wbudowane typy liczbowe i funkcje fabryczne .............................36 Sekwencje i elementy iterowalne ...............................................37 Listy .......................................................................................40 Łańcuchy znaków .....................................................................42 Sekwencyjne funkcje wbudowane i fabryczne .............................48 Typ odwzorowań — słownik ......................................................49 Podsumowanie typów standardowych ........................................52 Kontrola przepływu ........................................................................52 Instrukcje warunkowe ...............................................................52 Pętle .......................................................................................52 6 Python i Django. Programowanie aplikacji webowych Obsługa wyjątków ..........................................................................54 Klauzula finally ........................................................................55 Rzucanie wyjątkami z wykorzystaniem raise ...............................55 Pliki .............................................................................................56 Funkcje ........................................................................................57 Deklarowanie i wywoływanie funkcji ...........................................58 Funkcje są obiektami pierwszej klasy ........................................60 Funkcje anonimowe .................................................................61 *args i **kwargs .....................................................................63 Programowanie zorientowane obiektowo .........................................67 Definicje klas ..........................................................................68 Tworzenie egzemplarzy klas ......................................................68 Klasy pochodne .......................................................................69 Klasy wewnętrzne ....................................................................70 Wyrażenia regularne ......................................................................70 Moduł re .................................................................................71 Wyszukiwanie vs. dopasowywanie .............................................72 Typowe pułapki .............................................................................72 Jednoelementowa krotka ..........................................................72 Moduły ....................................................................................72 Zmienność (modyfikowalność) ..................................................74 Konstruktor vs. inicjalizator .......................................................76 Styl pisania kodu (PEP 8 i Beyond) .................................................77 Wcięcia — tylko z czterech spacji ..............................................78 Korzystaj ze spacji, a nie tabulacji .............................................78 Nie nadużywaj „jednolinijkowców” .............................................78 Twórz łańcuchy dokumentacji ....................................................78 Podsumowanie .............................................................................80 Rozdział 2 Django dla niecierpliwych — tworzymy blog ........................81 Tworzenie projektu ........................................................................82 Uruchamianie serwera ...................................................................84 Tworzenie bloga ............................................................................85 Projektowanie modelu ...................................................................86 Konfiguracja bazy danych ...............................................................87 Wykorzystywanie serwerów baz danych ......................................87 SQLite w praktyce ....................................................................88 Tworzenie tabel .......................................................................89 Konfiguracja automatycznej aplikacji administratora .........................90 Testowanie panelu administracyjnego .............................................91 Upublicznianie bloga .....................................................................95 Tworzenie szablonu ..................................................................96 Tworzenie funkcji widoku ..........................................................97 Tworzenie wzorca URL ..............................................................98 Spis treści 7 Końcowe poprawki ........................................................................99 (Nie)szablonowe rozwiązania .....................................................99 Sortowanie i porządkowanie wpisów ........................................100 Formatowanie znacznika czasu przy użyciu filtra szablonów .......101 Podsumowanie ...........................................................................102 Rozdział 3 Na dobry początek ...........................................................103 Podstawy dynamicznych stron internetowych .................................103 Komunikacja — HTTP, URL, żądania i odpowiedzi .....................104 Przechowywanie danych — SQL i relacyjne bazy danych ............104 Warstwa prezentacji — tworzenie dokumentów na podstawie szablonów ......................................................105 Łączenie elementów układanki ................................................105 Modele, widoki i szablony ............................................................106 Separacja warstw (MVC) .........................................................106 Modele danych ......................................................................107 Widoki ..................................................................................107 Szablony ...............................................................................108 Architektura Django — ogólne spojrzenie ......................................108 Filozofia programowania w Django ................................................110 Django ma być pythoniczne .....................................................110 Nie powtarzaj się (DRY)! .........................................................111 Luźne powiązania i elastyczność .............................................111 Błyskawiczne programowanie ..................................................112 Podsumowanie ...........................................................................112 113 Część II Django w szczegółach Rozdział 4 Tworzenie i używanie modeli .............................................115 Tworzenie modeli ........................................................................115 Dlaczego ORM? .....................................................................115 Typy pól w Django ..................................................................117 Relacje pomiędzy modelami ....................................................119 Dziedziczenie modeli ..............................................................123 Wewnętrzna klasa Meta .........................................................127 Rejestracja i opcje w panelu administratora .............................128 Wykorzystywanie modeli ..............................................................129 Tworzenie i modyfikowanie bazy danych za pomocą manage.py ....129 Składnia zapytań ...................................................................131 Wykorzystywanie funkcji SQL niedostępnych w Django ..............139 Podsumowanie ...........................................................................142 8 Python i Django. Programowanie aplikacji webowych Rozdział 5 URL, obsługa HTTP i widoki ..............................................145 Adresy URL .................................................................................145 Wprowadzenie do plików URLconf ...........................................145 url — metoda zamiast krotek ..................................................147 Wykorzystywanie wielu obiektów patterns ................................148 Dołączanie plików URL przy użyciu funkcji include .....................148 Obiekty funkcji vs. łańcuchy zawierające nazwy funkcji ..............149 HTTP w praktyce — żądania, odpowiedzi i warstwa pośrednicząca .....150 Obiekty żądań ........................................................................151 Obiekty odpowiedzi ................................................................154 Warstwa pośrednicząca ..........................................................154 Widoki — logika aplikacji .............................................................156 To tylko funkcje .....................................................................156 Widoki generyczne .................................................................157 Widoki półgeneryczne .............................................................159 Widoki własne .......................................................................160 Podsumowanie ...........................................................................162 Rozdział 6 Szablony i przetwarzanie formularzy ..................................163 Szablony ....................................................................................163 Konteksty ..............................................................................164 Składnia języka szablonów .....................................................164 Formularze .................................................................................170 Tworzenie formularzy ..............................................................170 Wypełnianie formularzy ...........................................................175 Walidacja i czyszczenie ...........................................................177 Wyświetlanie formularzy .........................................................178 Widgety .................................................................................180 Podsumowanie ...........................................................................182 183 Część III Przykładowe aplikacje Django Rozdział 7 Galeria zdjęć ....................................................................185 Model danych .............................................................................186 Wysyłanie plików .........................................................................187 Instalacja PIL ..............................................................................188 Testowanie pola ImageField .........................................................189 Tworzenie własnego pola do wysyłania plików ................................190 Inicjalizacja ...........................................................................192 Dodawanie atrybutów do pola .................................................194 Zapisywanie i usuwanie miniatury ...........................................195 Wykorzystujemy pole ThumbnailImageField ....................................196 Adresy URL zgodne z regułą DRY ..................................................196 Schematy adresów URL w aplikacji Item .......................................199 Spis treści 9 Wiązanie aplikacji z szablonami ....................................................201 Podsumowanie ...........................................................................205 Rozdział 8 System zarządzania treścią ..............................................207 CMS — z czym to się je? .............................................................207 Anty-CMS — strony płaskie ..........................................................208 Włączanie aplikacji Flatpages ..................................................208 Szablony stron płaskich ..........................................................210 Testowanie ............................................................................211 CMS — prosty, ale własny! ..........................................................211 Tworzenie modelu ..................................................................212 Instrukcje importujące ............................................................214 Uzupełnianie modeli ...............................................................214 Kontrola widoczności artykułów ...............................................215 Wykorzystujemy Markdown .....................................................216 Wzorce URL w pliku urls.py .....................................................218 Widoki administratora ............................................................219 Wyświetlanie treści przy użyciu widoków generycznych ..............221 Układ szablonów ....................................................................223 Wyświetlanie artykułów ...........................................................224 Dodajemy funkcję wyszukiwania ..............................................226 Zarządzanie użytkownikami .....................................................228 Wspieranie przepływu pracy ....................................................229 Poszerzanie możliwości systemu ..................................................229 Podsumowanie ...........................................................................231 Rozdział 9 Liveblog ...........................................................................233 Czym tak naprawdę jest Ajax? ......................................................234 Dlaczego Ajax? ......................................................................234 Projekt aplikacji ..........................................................................235 Wybieramy bibliotekę Ajaksa ...................................................235 Przygotowywanie aplikacji ............................................................236 Dodajemy kod Ajaksa ..................................................................240 Podstawy ..............................................................................240 „X” w Ajax (czyli XML vs. JSON) ...............................................241 Instalacja biblioteki JavaScript ................................................242 Konfiguracja i testowanie jQuery .............................................243 Tworzenie funkcji widoku ........................................................244 Wykorzystywanie funkcji widoku przy użyciu kodu JavaScript ......246 Podsumowanie ...........................................................................247 Rozdział 10 Schowek .........................................................................249 Definicja modelu .........................................................................250 Tworzenie szablonów ...................................................................251 Obsługa adresów URL .................................................................253 10 Python i Django. Programowanie aplikacji webowych Testowanie aplikacji ....................................................................254 Ograniczanie liczby ostatnio dodanych wpisów ...............................258 Podświetlanie składni ..................................................................259 Czyszczenie wpisów przy użyciu zadania programu Cron .................260 Podsumowanie ...........................................................................261 Część IV Zaawansowane funkcje i mechanizmy w Django 263 Rozdział 11 Zaawansowane programowanie w Django .........................265 Dostosowywanie panelu administratora ........................................265 Zmiana wyglądu i stylów przy użyciu obiektu fieldsets ...............266 Rozszerzanie bazowych szablonów ..........................................268 Dodawanie nowych widoków ...................................................269 Dekoratory uwierzytelniania ....................................................270 Wykorzystywanie aplikacji Syndication ...........................................271 Klasa Feed ............................................................................271 Przekazywanie adresu URL do źródła .......................................272 Jeszcze więcej źródeł! ............................................................273 Udostępnianie plików do pobrania ................................................273 Pliki konfiguracyjne Nagios .....................................................274 vCard ....................................................................................275 Wartości rozdzielone przecinkami (CSV) ...................................276 Wykresy i grafiki — moduł PyCha ............................................277 Rozszerzanie możliwości systemu ORM przy użyciu własnych menedżerów ..............................................279 Zmiana domyślnego zbioru obiektów .......................................279 Dodawanie metod do menedżera ............................................280 Rozszerzanie systemu szablonów .................................................281 Własne znaczniki szablonów ...................................................281 Znaczniki dołączania ..............................................................285 Własne filtry ..........................................................................287 Jeszcze więcej o złożonych szablonach znaczników ...................289 Alternatywne systemy szablonów .............................................290 Podsumowanie ...........................................................................292 Rozdział 12 Zaawansowane wdrażanie aplikacji ..................................293 Tworzenie pomocniczych skryptów ................................................293 Czyszczenie niepotrzebnych elementów przy użyciu zadań programu Cron ..........................................294 Import i eksport danych ..........................................................295 Modyfikowanie kodu Django .........................................................296 Buforowanie podręczne ...............................................................297 Podstawowy sposób buforowania ............................................297 Strategie buforowania ............................................................299 Rodzaje buforowania po stronie serwera ..................................304 Spis treści 11 Testowanie aplikacji w Django ......................................................307 Podstawy używania Doctest ....................................................308 Podstawy używania modułu Unittest ........................................308 Uruchamianie testów .............................................................309 Testowanie modeli .................................................................309 Testowanie całej aplikacji webowej ..........................................311 Testowanie kodu Django ........................................................312 Podsumowanie ...........................................................................313 Dodatki 315 Dodatek A Podstawy wiersza poleceń ................................................317 Wprowadzamy „polecenie” w „wierszu poleceń” ............................318 Opcje i argumenty .......................................................................320 Potoki i przekierowania ................................................................321 Zmienne środowiskowe ...............................................................323 Ścieżka ......................................................................................325 Podsumowanie ...........................................................................327 Dodatek B Instalacja i uruchamianie Django ......................................329 Python ........................................................................................329 Mac OS X ..............................................................................330 Unix i Linux ...........................................................................330 Windows ...............................................................................330 Aktualizacja ścieżki ................................................................331 Testowanie ............................................................................333 Opcjonalne dodatki ................................................................334 Django .......................................................................................336 Dostępne pakiety ...................................................................336 Wersja deweloperska .............................................................336 Instalacja ..............................................................................336 Testowanie ............................................................................337 Serwer WWW ..............................................................................337 Serwer wbudowany — nie w środowiskach produkcyjnych! ........337 Rozwiązanie standardowe — Apache i mod_python ..................338 Elastyczna alternatywa — WSGI ..............................................340 Podejście nr 3 — Flup i FastCGI ..............................................342 Baza danych SQL ........................................................................342 SQLite ..................................................................................343 PostgreSQL ...........................................................................343 MySQL ..................................................................................344 Oracle ...................................................................................346 Inne bazy danych ...................................................................346 Podsumowanie ...........................................................................346 12 Python i Django. Programowanie aplikacji webowych Dodatek C Narzędzia ułatwiające tworzenie aplikacji w Django ...........347 Systemy kontroli wersji ................................................................347 Gałęzie główne i rozwojowe .....................................................348 Scalanie ................................................................................348 Scentralizowana kontrola wersji ..............................................349 Zdecentralizowana kontrola wersji ...........................................349 Kontrola wersji w Twoim projekcie ...........................................350 Zarządzanie projektem programistycznym ......................................353 Trac ......................................................................................353 Edytory tekstowe .........................................................................354 Emacs ..................................................................................354 Vim .......................................................................................354 TextMate ...............................................................................354 Eclipse ..................................................................................354 Dodatek D Wyszukiwanie i wykorzystywanie aplikacji Django .............355 Poszukiwania gotowych aplikacji ...................................................356 Wykorzystywanie znalezionych aplikacji .........................................356 Jak wykorzystywać aplikacje? .......................................................357 Udostępnianie własnych aplikacji .................................................358 Dodatek E Django w Google App Engine ............................................359 Siła i magia App Engine ...............................................................360 App Engine (prawie) bez Django ....................................................360 Ograniczenia frameworka App Engine ............................................361 Helper App Engine dla Django ......................................................361 Pobieranie SDK i Helpera .......................................................361 Helper — więcej informacji .....................................................362 Aplikacje Django w App Engine .....................................................363 Kopiowanie kodu App Engine do projektu Django ......................363 Dodawanie obsługi Helpera App Engine ...................................363 Przenoszenie aplikacji do App Engine ......................................364 Testowanie aplikacji ...............................................................365 Dodawanie danych .................................................................365 Tworzenie nowej aplikacji Django w App Engine .............................366 Podsumowanie ...........................................................................367 W sieci .......................................................................................368 Dodatek F Twój udział w projekcie Django .........................................369 Skorowidz ........................................................................371 Kolofon ............................................................................389 Tworzenie modeli 115 4 Tworzenie i używanie modeli W rozdziale 3. dowiedziałeś się, że model danych w aplikacji WWW stanowi jej fundament. Z tego względu warto rozpocząć bliższe poznawanie Django właśnie od tego komponentu. Mimo że zgodnie z tytułem niniejszy rozdział został podzielony na dwie części — tworzenie i wykorzystywanie modeli — obie są ze sobą w dużej mierze powiązane. W trakcie projektowania powinniśmy zastanowić się, jak zamierzamy wykorzystywać modele, aby wygenerować najbardziej efektywny zestaw klas i relacji. Z drugiej strony, nie będziesz w stanie wykorzystywać modeli w odpowiedni sposób, jeśli nie zrozumiesz zasad ich tworzenia. Tworzenie modeli Warstwa danych w Django niezwykle intensywnie wykorzystuje maper obiektowo-relacyjny (ORM), dlatego warto się zastanowić, skąd wziął się pomysł wykorzystania tego narzędzia oraz jakie są plusy i minusy takiego rozwiązania. Niniejszy podrozdział zaczniemy więc od omówienia ORM-u zainstalowanego w Django, następnie zanalizujemy pola dostępne w modelach danych, sposoby tworzenia relacji pomiędzy klasami i modelami, a na koniec zapoznamy się z metadanymi modeli klas, używanymi do określania specyficznych zachowań modeli i zastosowania w panelu administracyjnym Django. Dlaczego ORM? Django, podobnie jak większość nowoczesnych frameworków sieciowych (podobnie jak wiele innych narzędzi do tworzenia aplikacji), wykorzystuje rozbudowaną warstwę dostępu do danych, która stanowi rodzaj pośrednika pomiędzy relacyjną bazą danych a aplikacjami tworzonymi w Pythonie. ORM-y stanowią przedmiot częstych dyskusji w społecznościach 116 Rozdział 4. Tworzenie i używanie modeli programistów. Django zostało zaprojektowane z myślą o intensywnym wykorzystaniu ORM-ów; zaprezentujemy poniżej cztery argumenty przemawiające za ich stosowaniem, z naciskiem na maper obecny w Django. Enkapsulacja użytecznych metod Obiekty modeli w Django są zdecydowanie najlepszą metodą definiowania kolekcji pól, które zazwyczaj odpowiadają kolumnom w bazie danych. Dzięki temu realizujemy pierwszą i zasadniczą czynność w odwzorowywaniu relacyjnej bazy danych na składniki programowania obiektowego. Zamiast tworzyć zapytanie SQL, np.: SELECT nazwisko FROM autorzy WHERE id=5, możesz zażądać obiektu Author, którego id ma wartość 5, a następnie sprawdzić pole author.name — jest to przykład zdecydowanie bliższy pythonicznemu podejściu do obsługi danych. Obiekty modeli zawierają o wiele większą funkcjonalność niż w powyższym opisie. ORM zawarty w Django, podobnie jak wiele innych, pozwala na określanie dodatkowych metod, dzięki którym możesz tworzyć następujące mechanizmy: (cid:132) Możesz tworzyć kombinacje pól i atrybutów tylko do odczytu, znane często pod nazwą pól wyliczanych. Na przykład obiekt Order, zawierający atrybuty count i cost, może zawierać także pole total, które stanowi iloczyn dwóch wcześniejszych pól. Zastosowanie typowych dla programowania obiektowego wzorców projektowych — fasad, delegacji — stanie się znacznie prostsze. (cid:132) ORM udostępnia możliwość zastąpienia domyślnych metod modyfikacji danych, takich jak zapisywanie czy usuwanie obiektów. Dzięki temu możesz wykonać dodatkowe operacje, zanim Twoje dane zostaną zapisane w bazie. Możesz też upewnić się, że aplikacja „posprząta po sobie”, zanim zostanie zrealizowana operacja usunięcia rekordu, niezależnie od tego, gdzie i jak to usunięcie zachodzi. (cid:132) Powiązanie z językiem programowania — w naszym przypadku z Pythonem — jest zazwyczaj proste, dzięki czemu Twoje obiekty bazy danych są zgodne z interfejsami i API udostępnianymi przez dany język. Przenośność Systemy ORM, będące warstwą kodu wiążącą bazę danych z resztą Twojej aplikacji, oferują niezwykłą przenośność. Większość platform ORM obsługuje wiele baz danych; podobnie jest w przypadku Django. Gdy piszemy tę książkę, warstwa danych Django obsługuje PostegreSQL, MySQL, SQLite i Oracle. Nie jest to, rzecz jasna, lista zamknięta — będzie ona rozbudowywana, w miarę tworzenia modułów obsługi do innych baz danych. Bezpieczeństwo W trakcie pracy z Django (lub innym frameworkiem wykorzystującym ORM) niezmiernie rzadko będziesz wykonywał własne zapytania. Dzięki temu nie będziesz musiał obawiać się o źle zaprojektowane i podatne na wstrzykiwanie kodu (ang. SQL injection) łańcuchy zapytań. ORM-y udostępniają także mechanizmy do zabezpieczania danych wejściowych Tworzenie modeli 117 (np. za pomocą inteligentnego cytowania znaków specjalnych), dzięki czemu nie musisz się o to martwić. Ten oczywisty pożytek wynika z zastosowanego podziału na warstwy, czego przykładem są frameworki oparte na wzorcu MVC. Gdy kod odpowiedzialny za dane zagadnienie jest dobrze zorganizowany, z pewnością bezpieczeństwo aplikacji wzrośnie, a Ty zaoszczędzisz swój cenny czas. Ekspresywność Choć cecha ta nie jest bezpośrednio związana z definicją modeli, jedną z największych zalet ORM-ów (i jednocześnie jedną z największych różnic w porównaniu z czystym kodem SQL) jest składnia zapytań wykorzystywanych do pobierania rekordów z bazy danych. Składnia wyższego poziomu jest nie tylko lepsza i łatwiejsza w trakcie pracy; przełożenie mechanizmu zapytań na realia Pythona pozwala na wykorzystywanie licznych jego zalet i technik. Jest na przykład możliwe utworzenie zapytań za pomocą iterowania po strukturach danych; w innej sytuacji zapytania te byłyby nieefektywne. Podejście to jest znacznie bardziej zwięzłe niż odpowiadający mu kod SQL. Pozwala też uniknąć bezsensownej manipulacji łańcuchami znaków, która w innym przypadku mogłaby być konieczna. Typy pól w Django Modele danych w Django obsługują wiele typów pól; niektóre z nich są bardzo blisko związane z ich bazodanową implementacją. Istnieją jednakże typy, które zostały zaprojektowane z myślą o formularzach stron internetowych. Większość typów można umieścić gdzieś pomiędzy tymi dwoma charakterystykami. Wyczerpującą listę typów znajdziesz w oficjalnej dokumentacji Django; w tym miejscu omówimy te najczęściej wykorzystywane. Na początku zapoznajmy się z podstawową definicją modelu. from django.db import models class Book(models.Model): title = models.CharField(max_length=100) author = models.ForeignKey(Author) length = models.IntegerField() Powyższy przykład powinien być dość czytelny — utworzyliśmy prosty model książki, oparty na licznych zasadach związanych z działaniem baz danych. Powyższy kod nie jest rozbudowany — katalogowanie książek to proces wymagający z reguły więcej informacji niż tytuł, autor i liczba stron — na nasze potrzeby jednak to wystarczy. Co więcej, powyższy model działa bez zarzutu. Mógłbyś dodać ten przykład do pliku models.py i być na najlepszej drodze do utworzenia prostego katalogu książek. Jak widać na powyższym przykładzie, Django wykorzystuje klasy Pythona do reprezentowania obiektów, które odwzorowują tabele SQL, zaś atrybuty tych obiektów odpowiadają kolumnom. Atrybuty te same w sobie również są obiektami, a dokładnie podklasami klasy Field. Niektóre z nich są prostymi odpowiednikami typów kolumn SQL, a inne dostarczają pewien poziom abstrakcji. Poniżej omawiamy niektóre z podklas klasy Field. 118 Rozdział 4. Tworzenie i używanie modeli (cid:132) CharField i TextField. Są to prawdopodobnie najczęściej używane pola, wykorzystywane do tego samego celu — przechowują tekst. Pola typu CharField mają stałą, skończoną długość, zaś TextField mogą przechowywać teoretycznie nieskończenie dużo tekstu. Wybór jednego z tych pól zależy od Twoich potrzeb (czy zamierzasz wykorzystywać przeszukiwanie pełnotekstowe (ang. fulltext search), czy też zależy Ci na oszczędności pamięci). (cid:132) EmailField, URLField i IPAddressField. Wszystkie te pola są w gruncie rzeczy polami CharField, jednak oferują one dodatkową walidację. W bazie danych są one przechowywane identycznie jak pole CharField, jednak dodatkowy kod zapewnia walidację, dzięki czemu możesz być pewien, że użytkownik wprowadził, odpowiednio, adres e-mail, adres URL lub adres IP. Do modeli danych możesz dodawać także własny kod walidacji, tworząc przez to własne „typy pól” na tym samym poziomie, na którym Django oferuje własne (zob. rozdziały 6. i 7., aby dowiedzieć się więcej o walidacji). (cid:132) BooleanField i NullBooleanField. BooleanField to dobry wybór w większości sytuacji, gdy chcesz przechowywać wartość True lub False. Czasami jednak musisz uwzględnić sytuację, w której nie znasz wartości — można wtedy interpretować wartość jako pustą lub null. Z takich wniosków powstał pomysł utworzenia pola NullBooleanField. To rozróżnienie wynika z faktu, że modelowanie danych musi być poprzedzone procesem analizy modelu — zarówno technicznej, jak i semantycznej. Musisz zastanowić się nie tylko nad tym, jak, ale i co przechowujesz. (cid:132) FileField. Pole typu FileField jest jednym z najbardziej złożonych pól, ponieważ większość pracy nie jest związana z bazą danych, tylko z obsługą żądania. Pole FileField przechowuje w bazie danych tylko ścieżkę do pliku, podobnie jak jego mniej funkcjonalny kolega — FilePathField. Pole FileField wyróżnia się możliwością wysłania pliku za pomocą przeglądarki użytkownika i przechowania go na serwerze. Udostępnia ono także metody odpowiedzialne za dostęp do wysłanego pliku za pomocą adresu URL. Powyższy wykaz zawiera tylko kilka z dostępnych w definicjach modeli Django. Kolejne wersje frameworka zawierają z reguły coraz bardziej rozbudowaną listę pól. Zapoznaj się z oficjalną dokumentacją Django, w której są umieszczane opisy wszystkich pól i ich klas. Możesz także zanalizować listingi z dalszej części książki, zwłaszcza z części III. Klucze główne i unikalność Jedną z najważniejszych konstrukcji związanych z relacyjnymi bazami danymi jest klucz główny. Klucz jest polem, którego wartości w całej tabeli muszą być unikalne (w systemach ORM mówimy o całym modelu). Klucze główne są z reguły polami automatycznie inkrementowanymi typu liczbowego, ponieważ inkrementacja stanowi najprostszą i najszybszą metodą sprawdzenia, czy każdy wiersz w tabeli ma unikalną wartość. Tworzenie modeli 119 Klucze główne są niezwykle przydatne jako punkty odniesienia dla relacji pomiędzy modelami (zostały one opisane w poniższych podrozdziałach) — jeśli dana książka ma ID = 5 i wiadomo, że istnieje tylko jedna książka o takim ID, możemy powiedzieć, że określenie książka #5 jest absolutnie jednoznaczne. Powyżej opisany typ klucza głównego jest powszechnie stosowany, dlatego Django tworzy automatycznie taki właśnie klucz, o ile nie określisz go jawnie. Wszystkie modele niezawierające jawnie określonego klucza głównego otrzymują atrybut id, będący polem typu AutoField (automatycznie inkrementowana liczba całkowita). Pola AutoField zachowują się jak zwykłe liczby całkowite; odpowiadający im typ kolumny w bazie danych zależy od wybranego systemu bazodanowego. Jeśli chcesz zyskać większą kontrolę nad wykorzystaniem kluczy głównych, przypisz wartość True właściwości primary_key dla pola, które ma zostać Twoim kluczem głównym. Pole to stanie się kluczem i zastąpi generowane pole id. Taki wybór oznacza, że wartości tego pola muszą być absolutnie unikatowe. Wykorzystywanie pola zawierającego łańcuch znaków (np. imię i nazwisko lub inne identyfikatory) nie jest dobrym wyborem, o ile nie jesteś pewien na 110 , że w tym polu nie było, nie ma i nie będzie duplikatów! Jeśli chcesz uczynić dowolne pole unikalnym, jednocześnie nie tworząc klucza głównego, możesz skorzystać z atrybutu Unique. Przypisanie temu atrybutowi wartości True dla danego pola gwarantuje jego unikalność bez konieczności nadawania klucza głównego. Relacje pomiędzy modelami Możliwość tworzenia relacji pomiędzy modelami jest jedną z najważniejszych zalet przemawiających za wykorzystywaniem relacyjnych baz danych. W tej kwestii systemy ORM mogą różnić się od siebie dość znacznie. Obecna implementacja w Django jest skupiona wokół baz danych, co oznacza, że relacje są definiowane na poziomie bazy danych, a nie tylko na poziomie aplikacji. Niestety, ze względu na fakt, że SQL udostępnia tylko jedną formę relacji — klucz obcy (ang. foreign key) — konieczne jest wprowadzenie dodatkowych mechanizmów na nieco wyższym poziomie w celu utworzenia bardziej zaawansowanych relacji. Najpierw zajmiemy się samym kluczem obcym, a później zastosowaniem go do tworzenia innych typów relacji. Klucze obce Zasada działania kluczy obcych jest prosta, dlatego nie inaczej jest w przypadku ich implementacji w Django. Są one reprezentowane za pomocą klasy ForeignKey (podklasy klasy Field). Pierwszy argument tej klasy stanowi klasę modelu, do którego chcemy się odwołać, jak w poniższym przykładzie: class Author(models.Model): name = models.CharField(max_length=100) class Book(models.Model): title = models.CharField(max_length=100) author = models.ForeignKey(Author) 120 Rozdział 4. Tworzenie i używanie modeli Klasy, do których odwołujemy się za pomocą kluczy obcych, muszą być zadeklarowane przed klasami, w których klucze obce są używane. Inaczej nazwa Author nie mogłaby być wykorzystywana w klasie Book, w polu typu ForeignKey. Możesz też korzystać z łańcucha znaków, podając nazwę klasy (jeśli jest zdefiniowana w tym samym pliku) lub korzystając z notacji kropkowej (np. myapp.Author ). Poniżej znajduje się przykład zapisany z wykorzystaniem klucza obcego zawierającego łańcuch znaków: class Book(models.Model): title = models.CharField(max_length=100) author = models.ForeignKey( Author ) class Author(models.Model): name = models.CharField(max_length=100) Istnieje możliwość tworzenia kluczy obcych odwołujących się do modelu, w którym zostały zadeklarowane, za pomocą słowa self . Takie rozwiązanie jest często spotykane przy tworzeniu struktur hierarchicznych (np. klasa Pojemnik zawiera atrybut parent umożliwiający tworzenie zagnieżdżonych pojemników) lub podobnych konstrukcji (na przykład klasa Pracownik zawierająca atrybuty przełożony lub kierownik). Mimo że klucz obcy jest definiowany tylko po jednej stronie relacji, druga strona również jest zdolna podłączyć się do relacji. Klucze obce tworzą relację wiele do jednego (ang. many-to-one), ponieważ wiele obiektów „dzieci” może odwoływać się do tego samego obiektu „rodzica”. Jedno dziecko może być powiązane z jednym rodzicem, ale jeden rodzic może dysponować grupą dzieci. Korzystając z powyższego przykładu, możesz wykorzystywać instancje modeli Book i Author w następujący sposób: # Zdejmij książkę z półki – zapoznaj się z podrozdziałem poświęconym zapytaniom. book = Book.objects.get(title= Moby Dick ) # Pobierz autora książki – proste, nieprawdaż? author = Book.author # Pobierz wszystkie książki danego autora books = author.book_set.all() Jak widać w powyższym przykładzie, „odwrócenie” relacji od modelu Author do Book jest reprezentowane za pomocą atrybutu Author.book_set (jest to menedżer obiektu, opisany w dalszej części rozdziału), który jest generowany automatycznie przez ORM. Możesz zmienić tę konwencję nazewniczą, modyfikując argument related_name obiektu ForeignKey; w poprzednim przykładzie mogliśmy zdefiniować atrybut author jako ForeignKey( Author , related_name= books ). Moglibyśmy wtedy odwoływać się do atrybutu author.books zamiast author.book_set. Uwaga Wykorzystanie atrybutu related_name jest opcjonalne w przypadku prostych hierarchii obiektów. W praktyce jest to konieczne w przypadku bardziej złożonych relacji, na przykład gdy dysponujesz wieloma kluczami obcymi wiążącymi jeden obiekt z innymi. W takiej sytuacji ORM zasygnalizuje Ci istnienie dwóch menedżerów odwrotnych relacji przez wyświetlenie komunikatu o błędzie! Tworzenie modeli 121 Relacje „wiele do wielu” Klucze obce są wykorzystywane do tworzenia relacji jeden do wielu (lub wiele do jednego) — w poprzednich przykładach każdy obiekt Book ma przypisany jeden obiekt Author, a jeden obiekt Author może mieć wiele obiektów Book. Czasami konieczna jest większa swoboda. Do tej pory zakładaliśmy, że każda książka została napisana przez jednego autora. Cóż jednak począć z książkami, które były pisane przez wiele osób, jak chociażby książka, którą właśnie czytasz? Taka sytuacja wymaga wykorzystania relacji „wiele” po obu stronach (każda książka może mieć wielu autorów, a każdy autor może mieć wiele książek). Jest to idealny przykład relacji wiele do wielu. SQL nie wprowadza definicji takiej relacji, dlatego musimy utworzyć ją, korzystając z kluczy obcych. Django udostępnia specjalne pole, które ułatwia obsługę takiej sytuacji: ManyToManyField. Pod względem składni działa ono identycznie jak ForeignKey. Definiuje się je po jednej ze stron relacji (przekazując model drugiej strony relacji jako argument), a ORM automatycznie przyznaje drugiej stronie zestaw niezbędnych metod i atrybutów do obsługi relacji (z reguły polega to na utworzeniu menedżera, podobnie jak w przypadku kluczy obcych). Co ważne, pole typu ManyToManyField możesz utworzyć po dowolnej stronie relacji. Wybór strony nie ma znaczenia, ponieważ relacja ta jest symetryczna. Uwaga Jeśli zamierzasz wykorzystać panel administracyjny Django, pamiętaj, że formularze dla obiektów w relacji „wiele do wielu” wyświetlają pole formularza tylko po stronie, w której relacja została zdefiniowana. Uwaga Pola ManyToManyField odwołujące się do siebie (tzn. pole, które zdefiniowane w danym modelu odwołuje się do tego samego modelu) są symetryczne, ponieważ relacja jest obustronna. Nie zawsze jest to jednak najlepsze rozwiązanie, dlatego warto zmienić domyślne zachowanie, określając właściwość symmetrical = False w definicji pola. Zaktualizujmy nasz przykład o obsługę książek napisanych przez wielu autorów: class Author(models.Model): name = models.CharField(max_length=100) class Book(models.Model): title = models.CharField(max_length=100) authors = models.ManyToManyField(Author) Pola ManyToManyField są wykorzystywane podobnie jak strona „wiele” w zwykłej relacji z pojedynczym kluczem obcym: # Zdejmij książkę z półki book = Book.objects.get(title= Python Web Development Django ) # Pobierz autorów książek authors = Book.author_set.all() 122 Rozdział 4. Tworzenie i używanie modeli # Pobierz książki, których autorem jest trzeci z autorów books = authors[2].book_set.all() Pole ManyToManyField w celu poprawnej obsługi relacji tworzy zupełnie nową tabelę, w której wykorzystujemy znany już mechanizm kluczy obcych. Każdy wiersz tej tabeli zawiera pojedynczą relację między dwoma obiektami, w której skład wchodzą klucze obce do obu obiektów! Powyższa tabela jest ukryta przed użytkownikiem Django i dostępna jedynie dla ORM-ów. Nie można zatem wywoływać na niej zapytań; jedynym sposobem jej wykorzystywania jest odwoływanie się za pomocą jednej ze stron relacji. Jest jednak możliwe określenie specjalnej opcji w polu ManyToManyField (through), dzięki której można jawnie zdefiniować klasę modelu pośredniego (własną klasę obsługującą wyżej opisaną tabelę). Dzięki użyciu opcji through możesz zdefiniować dodatkowe pola w modelu pośrednim, jednocześnie zachowując możliwość wykorzystywania menedżerów po obu stronach relacji. Poniższy kod działa identycznie jak przykład z polem ManyToManyField, jednak dołączyliśmy jawnie tabelę pośredniczącą Authoring, która dodaje pole collaboration_type do relacji. Przy tworzeniu relacji uwzględniliśmy też parametr through wskazujący na tabelę Authoring. class Author(models.Model): name = models.CharField(max_length=100) class Book(models.Model): title = models.CharField(max_length=100) authors = models.ManyToManyField(Author, through= Authoring ) class Authoring(models.Model): collaboration_type = models.CharField(max_length=100) book = models.ForeignKey(Book) author = models.ForeignKey(Author) Możesz odpytywać obiekty Author i Book w ten sam sposób, jak w poprzednich przykładach. Możesz też tworzyć zapytania związane z tabelą authoring. # Pobierz wszystkie eseje, których współautorem jest Chun chun_essay_compilations = Book.objects.filter( author__name__endswith= Chun , authoring__collaboration_type= essays ) Mechanizm ten znacząco rozbudowuje elastyczność Django w zakresie tworzenia relacji. Relacje „jeden do jednego” Poza najczęściej spotykanymi relacjami „wiele do jednego” i „wiele do wielu” relacyjne bazy danych pozwalają na wykorzystanie trzeciego typu relacji: jeden do jednego. Podobnie jak poprzednie typy, tak i ten działa zgodnie ze swoją nazwą — po obu stronach relacji znajduje się tylko jeden obiekt. Tworzenie modeli 123 Django wykorzystuje tę relację za pomocą pola OneToOneField, które również stosuje zasadę działania obiektu ForeignKey — pobiera jeden argument, czyli klasę, z którą chcemy utworzyć relację (lub łańcuch znaków self , jeśli odwołujemy się do tego samego modelu). Podobnie jak w przypadku obiektu ForeignKey, możemy podać argument related_name, dzięki czemu możemy korzystać z wielu relacji w przypadku dwóch takich samych klas. W przeciwieństwie do pozostałych relacji, pole OneToOneField nie udostępnia menedżera do zarządzania odwrotną relacją, ponieważ zawsze istnieje tylko jeden obiekt (w obydwu kierunkach). Ten typ relacji jest najczęściej wykorzystywany do zdefiniowania obiektów złożonych lub określenia własności (przynależności jednego obiektu do innego). Jest on częściej wykorzystywany w realiach programowania obiektowego niż w świecie rzeczywistym. Zanim Django zaczęło obsługiwać dziedziczenie modeli bezpośrednio, pole OneToOneField było wykorzystywane do implementacji relacji pseudodziedziczenia. Ograniczanie relacji Na zakończenie warto zwrócić uwagę, że jest możliwe — zarówno w przypadku kluczy obcych, jak i relacji „wiele do wielu” — określenie własności limit_choices_to. Argument ten pobiera słownik, którego pary klucz-wartość określają słowa kluczowe zapytania i wartości (o słowach kluczowych zapytań piszemy poniżej). Dzięki temu argumentowi możesz określić zakres możliwych wartości dla relacji, którą tworzysz. Poniższy model działa poprawnie tylko w odniesieniu do autorów, których nazwisko kończy się łańcuchem Smith: class Author(models.Model): name = models.CharField(max_length=100) class SmithBook(models.Model): title = models.CharField(max_length=100) authors = models.ManyToManyField(Author, limit_choices_to={ name__endswith : Smith }) Uwaga Istnieje możliwość — a czasami jest to zalecane — aby tego typu ograniczenia stosować na poziomie formularza. Przeczytaj opis pola ModelChoiceField i ModelMultipleChoiceField w rozdziale 6. Dziedziczenie modeli Dość niedawno w ORM-ie zainstalowanym w Django zostało wprowadzone dziedziczenie modeli. Poza kluczami obcymi i innymi rodzajami relacji istnieje możliwość definiowania modeli, które dziedziczą po sobie w tradycyjny sposób, znany z innych klas Pythona (przykłady zwykłego dziedziczenia zostały umieszczone w rozdziale 1.). 124 Rozdział 4. Tworzenie i używanie modeli Na przykład klasa SmithBook jest całkowicie samodzielną klasą, która nieprzypadkowo udostępnia takie same pola jak klasa Book. Skoro między obydwiema klasami występuje takie podobieństwo, klasę SmithBook moglibyśmy uczynić klasą pochodną klasy Book. Korzyści są oczywiste — podklasa musi definiować tylko pola, które chce dodać bądź zmienić w stosunku do klasy nadrzędnej. Nasza klasa Book nie jest zbyt skomplikowanym przykładem, jednak można wyobrazić sobie bardziej realistyczny model, zawierający dziesiątki atrybutów i skomplikowane metody. W takiej sytuacji dziedziczenie okazuje się jedną z kluczowych dróg do spełnienia opisanej w rozdziale 3. zasady DRY. Pamiętaj jednak, że w celu osiągnięcia tego samego efektu cały czas możesz korzystać z kluczy obcych i pól OneToOneField. To, którą technikę wybierzesz, zależy wyłącznie od Ciebie i Twojej wizji modelu danych. Django udostępnia dwa sposoby dziedziczenia: abstrakcyjne klasy bazowe i dziedziczenie po wielu tabelach. Abstrakcyjne klasy bazowe Dziedziczenie z użyciem klas bazowych polega w dużym uproszczeniu na wykorzystaniu mechanizmów dziedziczenia opartych tylko na Pythonie — pozwala to na zwykłe dziedziczenie wspólnych pól i metod z klas bazowych. Na poziomie bazy danych i zapytań klasy bazowe nie istnieją, tak więc ich pola są duplikowane w tabelach baz danych ich dzieci. Powyższe stwierdzenie brzmi jak naruszenie zasady DRY, jednak istnieją sytuacje, w których nie chcesz tworzyć dodatkowej tabeli dla klasy bazowej. Może się tak zdarzyć, jeśli z Twojej bazy danych korzystają inne aplikacje. Jest to także sposób na utworzenie bardziej eleganckich definicji klas bez zmiany aktualnej hierarchii obiektów. Zmieńmy nieco hierarchię modeli Book i SmithBook, korzystając z abstrakcyjnych klas bazowych. class Author(models.Model): name = models.CharField(max_length=100) class Book(models.Model): title = models.CharField(max_length=100) genre = models.CharField(max_length=100) num_pages = models.IntegerField() authors = models.ManyToManyField(Author) def __unicode__(self): return self.title class Meta: abstract = True class SmithBook(Book): authors = models.ManyToManyField(Author, limit_choices_to={ name__endswith : Smith }) Tworzenie modeli 125 Najważniejsza w powyższym kodzie jest deklaracja abstract = True w wewnętrznej klasie Meta klasy Book. Oznacza ona, że klasa Book jest abstrakcyjną klasą bazową i istnieje tylko po to, aby udostępnić swoje atrybuty klasom modeli, które po niej dziedziczą. Zauważ, że klasa SmithBook nadpisuje pole authors tylko po to, aby uzupełnić je o parametr limit_choices_to. Dzięki temu, że klasa SmithBook dziedziczy po Book (zamiast standardowej models.Model), baza danych będzie zawierać kolumny title, genre i num_pages, podobnie jak tabelę pomocniczą do relacji „wiele do wielu”. Klasa zawiera także typową dla Pythona metodę __unicode__, która zwraca pole title, podobnie jak klasa Book. Innymi słowy, zarówno w momencie tworzenia bazy danych, jak i w momencie tworzenia obiektów, odpytywania ORM-u itd. klasa SmithBook zachowuje się dokładnie tak, jakby była zdefiniowana następująco: class SmithBook(models.Model): title = models.CharField(max_length=100) genre = models.CharField(max_length=100) num_pages = models.IntegerField() authors = models.ManyToManyField(Author, limit_choices_to={ name__endswith : Smith }) def __unicode__(self): return self.title Powyższa konstrukcja rozszerza mechanizm zapytań podobnie jak atrybuty instancji SmithBook, dlatego poniższe zapytanie będzie absolutnie poprawne: smith_fiction_books = SmithBook.objects.filter(genre= Fiction ) Nasz przykład nie jest w pełni dostosowany do abstrakcyjnych klas bazowych, ponieważ chciałbyś zapewne tworzyć zarówno egzemplarze klasy Book, jak i SmithBook. Abstrakcyjne klasy bazowe są, rzecz jasna, abstrakcyjne — nie można tworzyć bezpośrednio egzemplarzy tych klas. Są one najbardziej użyteczne w celu spełniania reguły DRY na poziomie definicji modelu. Dziedziczenie oparte na wielu tabelach jest znacznie lepszym rozwiązaniem dla tej, konkretnej sytuacji. Na zakończenie zauważmy jeszcze dodatkowe cechy abstrakcyjnych klas bazowych — wewnętrzna klasa Meta w klasach pochodnych dziedziczy po klasie Meta (lub jest łączona z nią) znajdującej się w klasie bazowej (oczywiście z pominięciem atrybutu abstract, który jest ponownie ustawiany na False, podobnie jak inne atrybuty, określone dla konkretnej bazy danych, np. db_name). Co więcej, jeśli klasa bazowa wykorzystuje argument related_name do określenia relacyjnego pola, takiego jak ForeignKey, musisz skorzystać z formatowania łańcuchów, dzięki czemu klasy pochodne nie spowodują konfliktów. Nie korzystaj ze zwykłego łańcucha, np. related_pracownicy ; umieść w nim ciąg (class)s, np. related_ (class)s (przypomnij sobie fragmenty rozdziału 1., jeśli nie pamiętasz sposobu zamiany łańcuchów znaków). W ten sposób nazwy klas pochodnych są zamieniane poprawnie i nie występują konflikty. 126 Rozdział 4. Tworzenie i używanie modeli Dziedziczenie po wielu tabelach Dziedziczenie po wielu tabelach wydaje się tylko nieznacznie różne od abstrakcyjnych klas bazowych, przynajmniej na poziomie definicji. W tym mechanizmie również wykorzystuje się dziedziczenie klas Pythona, jednak pomijamy atrybut abstract=True w klasie Meta. W trakcie korzystania z egzemplarzy modeli czy wykonywania zapytań na nich dziedziczenie po wielu tabelach ponownie wygląda bardzo podobnie do poprzedniego rozwiązania. Klasa pochodna wydaje się dziedziczyć wszystkie atrybuty i metody klasy bazowej (z wyjątkiem klasy Meta, co wyjaśnimy poniżej). Główna różnica między obydwoma rodzajami dziedziczenia polega na wewnętrznych mechanizmach odpowiadających za działanie. Klasy bazowe w tym przypadku są pełnoprawnymi modelami Django z własnymi tabelami i mogą być tworzone egzemplarze tych klas, podobnie jak ich atrybuty mogą być przekazywane do klas pochodnych. Jest to realizowane za pomocą automatycznego pola OneToOneField pomiędzy klasami pochodnymi i klasami bazowymi. Następnie są wykonywane czynności wiążące dwa obiekty i klasa pochodna dziedziczy atrybuty klasy bazowej. Innymi słowy, dziedziczenie oparte na wielu tabelach stanowi „opakowanie” zwykłej relacji posiadania (sytuacja ta jest znana pod nazwą składania (złożenia) obiektów. Django ze względu na swoją pythoniczność jawnie definiuje ukrytą zazwyczaj relację. Nosi ona nazwę klasy bazowej (pisaną małymi literami) z sufiksem _ptr. Na przykład poniższy listing wprowadza atrybut book_ptr klasy SmithBook, który wskazuje na klasę bazową Book. Poniższy kod przedstawia dziedziczenie wielotabelowe klas Book i SmithBook: class Author(models.Model): name = models.CharField(max_length=100) class Book(models.Model): title = models.CharField(max_length=100) genre = models.CharField(max_length=100) num_pages = models.IntegerField() authors = models.ManyToManyField(Author) def __unicode__(self): return self.title class SmithBook(Book): authors = models.ManyToManyField(Author, limit_choices_to={ name__endswith : Smith }) Jedyną różnicą w tym momencie jest brak atrybutu abstract w klasie Meta. Uruchomienie polecenia manage.py syncdb na pustej bazie danych z plikiem models.py o powyższej treści spowoduje utworzenie trzech głównych tabel, podczas gdy wykorzystanie abstrakcyjnych klas bazowych spowodowałoby utworzenie jedynie dwóch tabel — Author i SmithBook. Zauważ, że instancje klasy SmithBook otrzymują atrybut book_ptr, który wiedzie do instancji klasy Book, zaś obiekty klasy Book, które należą do określonego obiektu SmithBook, otrzymują atrybut smithbook (bez sufiksu _ptr). Tworzenie modeli 127 Ta forma dziedziczenia pozwala klasom bazowym na tworzenie własnych egzemplarzy. Z tego względu dziedziczenie klasy Meta mogłoby spowodować problemy lub konflikty pomiędzy obydwiema stronami relacji. Z tego względu musisz zdefiniować ponownie większość opcji klasy Meta, które w przeciwnym razie były udostępniane pomiędzy obydwiema klasami (mimo że parametry ordering i get_latest_by są dziedziczone, o ile nie zostały zdefiniowane w klasie pochodnej). Rozwiązanie takie utrudnia spełnienie zasady DRY, ale, jak już wspomnieliśmy, nie zawsze regułę tę można bezwzględnie spełniać. Mamy nadzieję, że wyjaśniliśmy, dlaczego ten rodzaj dziedziczenia jest lepszy dla naszego modelu z książkami. Możemy tworzyć zarówno egzemplarze klasy Book, jak i obiekty SmithBook. Jeśli korzystasz z dziedziczenia modeli, aby odwzorować relacje istniejące w realnym świecie, istnieje większa szansa, że skorzystasz z dziedziczenia po wielu tabelach zamiast abstrakcyjnych klas bazowych. Umiejętność wyboru jednego z rozwiązań przychodzi z czasem i nabytym doświadczeniem. Wewnętrzna klasa Meta Pola i relacje, które definiujesz w modelach, są używane przy tworzeniu bazy danych. Mają one wpływ na nazwy zmiennych, których używasz przy późniejszym odpytywaniu modelu. Często będziesz też dodawać w modelu takie metody, jak __unicode__, get_absolute_url, lub zmieniać wbudowane metody save albo delete. Na końcowy kształt modelu ma również wpływ wewnętrzna klasa, która uwzględnia w Django rozmaite metadane związane z modelem. Jest to klasa Meta. Klasa Meta, jak sama nazwa wskazuje, zajmuje się obsługą metadanych związanych z modelem — zarówno dotyczących użycia, jak i wyświetlania, np. jak powinna być wyświetlana jego nazwa w odniesieniu do pojedynczego obiektu, a jak w przypadku wielu obiektów, jaki powinien być domyślny porządek sortowania, jaka jest nazwa tabeli itd. Klasa Meta jest miejscem, w którym określamy także unikalność wielopolową, ponieważ nie miałoby sensu definiowanie takiej własności w deklaracji zwykłego pola. Dodajmy proste metadane do naszego pierwszego przykładu opartego na klasie Book. class Book(models.Model): title = models.CharField(max_length=100) authors = models.ManyToManyField(Author) class Meta: # Porządek alfabetyczny ordering = [ title ] Klasa Book jest na tyle prosta, że nie musimy korzystać z większości opcji klasy Meta. Gdyby nie zależało nam na porządku sortowania, moglibyśmy całkowicie pominąć deklarację klasy. Klasy Admin i Meta są całkowicie opcjonalną częścią deklaracji modelu, jednak nie oznacza to, że są rzadko wykorzystywane. Zapoznajmy się z nieco bardziej skomplikowanym przykładem, ponieważ metadane klasy Book są dość nudne. 128 Rozdział 4. Tworzenie i używanie modeli class Person(models.Model): first = models.CharField(max_length=100) last = models.CharField(max_length=100) middle = models.CharField(max_length=100, blank=True) class Meta: # Jest to odpowiednia metoda porządkowania, jeśli założymy, że osoby będą wyświetlane # w kolejności nazwisko (last), pierwsze imię (first), drugie imię (middle) ordering = [ last , first , middle ] # W tym miejscu zakładamy, że nie istnieją dwie osoby o takich samych imionach i nazwiskach # Oczywiście w świecie rzeczywistym jest to możliwe, niemniej zakładamy, że jest to # świat idealny. unique_together = [ first , last , middle ] # Według domyślnych ustawień Django dodaje literę s , aby wyrazić liczbę mnogą. W tym przypadku # jest to złe rozwiązanie verbose_name_plural = people Utworzenie modelu osoby bez wykorzystania klasy Meta byłoby niezwykle trudnym zadaniem. Przy sortowaniu musimy uwzględnić wszystkie trzy pola; co więcej, musimy uniknąć powstania duplikat
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Python i Django. Programowanie aplikacji webowych
Autor:
, ,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: