Ten dokument wyjaśnia podstawowe filozofie, którymi kierowali się deweloperzy Django podczas tworzenia frameworku. Celem jest wytłumaczenie przeszłości i pokierowanie przyszłością.
\nFundamentalną zasadą stosu Django jest loose coupling and tight cohesion. Różnorodne warstwy frameworka nie powinny wiedzieć o innych więcej niż to absolutnie konieczne.
\nNa przykład, szablon nie wie nic o żądaniu, warstwa bazy danych nie wie nic o wyświetlaniu danych a widok nie martwi się szablonem używanym przez programistę.
\nJednakże Django przychodzi z pełnym zestawem dla wygody, a części zestawu są ze sobą niezależne gdzie tylko to możliwe.
\nAplikacje Django powinny używać tak mało kodu jak to możliwe. Django powinno w pełni wykorzystywać dynamiczne możliwości Pythona, tak jak w introspekcji.
\nNajważniejszym punktem w frameworku 21-ego wieku jest szybkie wykonanie powtarzalnych aspektów tworzenia strony internetowej. Django powinno pozwolić na niesamowicie szybkie wytwarzanie oprogramowania.
\nKażdy unikalny pomysł i/lub część danych powinny żyć w jednym i tylko jednym miejscu. Redundancja jest zła. Normalizacja jest dobra.
\nFramework, w granicach rozsądku, powinien domyślić się ile to możliwe z możliwe małej ilości danych.
\n\nTo jest główna zasada Pythona zapisana w PEP 20, i oznacza że Django nie powinno wykonywać zbyt dużo „magii”. Magia nie powinna się zdarzyć bez naprawdę dobrego powodu. Magia jest warta użycia tylko jeśli stworzy ogromną wygodę nieosiągalną w inny sposób i nie zostanie zaimplementowana w sposób, który będzie dezorientował programistów próbujących nauczyć się jak ją wykorzystać.
\nFramework powinien być na spójny na każdym poziomie. Spójność dotyczy każdego poziomu od niskiego (używania stylu programowaniu w Pythonie) aż po wysoki (doświadczenie z używania Django).
\nPola nie powinny przyjmować pewnych zachowań bazując jedynie na nazwie pola. To wymaga zbyt dużo wiedzy o systemie i jest podatne na błędy. Natomiast, zachowania powinny bazować na kluczowych argumentach i, w niektórych przypadkach na typie pola.
\nModele powinny hermetyzować każdy aspekt obiektu, zgodnie z wzorcem projektowym Active Record, którego autorem jest Martin Fowler.
\nTo jest powód dla którego dane zarówno reprezentowane przez model i informacje o nim (to jest nazwa czytelna dla człowieka, opcje jak np. domyślne sortowanie itp.) są trzymane w klasie modelu; wszystkie informacje potrzebne do zrozumienia danego modelu powinny być w nim przechowywane.
\nPodstawowymi celami API baz danych są:
\nPowinno się wykonywać zapytanie SQL tak rzadko jak to możliwe, dodatkowo powinno się optymalizować zapytania wewnętrznie.
\nTo jest powód dla którego programiści muszą odwołać się do save() wprost, a framework nie robi tego po cichu w tle.
To jest dodatkowy powód dlaczego metody select_related() QuerySet istnieją. Jest to opcjonalne poprawienie wydajności dla częstych przypadków wybierania „każdego powiązanego obiektu”.
Interfejs bazy danych API powinien udostępniać bogatą, wyrazistą składnię przy możliwie małych nakładzie kodu. Nie powinien polegać na importowaniu innych modułów lub pomocniczych obiektów.
\nPołączenia tabel powinny być wykonywane automatycznie, w tle jeśli jest to konieczne.
\nKażdy obiekt powinien mieć dostęp do każdego obiektu z którym jest w relacji, w danym systemie. Ten dostęp powinien być obustronny.
\nAPI bazy danych powinno zauważać, że jest to skrót a niekoniecznie wszystko. Framework powinien ułatwiać pisanie spersonalizowanego SQL - całych formuł lub tylko własnych klauzuli WHERE jako własne parametry na wywołania API.
URLe w aplikacji Django nie powinny być połączone z podstawowym kodem Pythona. Łączenie URLi wraz z nazwami funkcji Pythona nazywa się Złą i Brzydką Rzeczą.
\nPoza tym, system URL Django powinien pozwalać, by adresy URL tej samej aplikacji były różne w zależności od kontekstu. Na przykład, jedna strona może przechowywać historie w /stories/, a inna może używać /news/.
URLe powinny być elastyczne jak to tylko możliwe. Każdy wyobrażalny URL powinien być dostępny.
\nFramework powinien pozwalać programiście łatwo (albo nawet łatwiej) tworzyć ładne URLe niż brzydkie.
\nRozszerzenia plików w URLu strony internetowej powinny być unikane.
\nPrzecinki w URLach zasługują na surową karę.
\nW zasadzie, foo.com/bar i``foo.com/bar/`` są dwoma różnymi URLami, roboty wyszukiwarkowe (oraz niektore narzędzia analizujące ruch w sieci) mogłyby potraktować je jako oddzielne strony. Django powinno postarać się „normalizować” URLe aby roboty wyszukiwarkowe nie były zdezorientowane.
To uzasadnia używanie ustawienia APPEND_SLASH
Widzimy, że system szablonów jako narzędzie kontroli prezentacji i prezentacja zorientowana na logikę to jest to. System szablonów nie powinien wspierać funkcjonalności wykraczających poza ten cel.
\nWiele z dynamicznych stron internetowych używa pewnego wspólnego sposobu projektowania - np. nagłówek, stopka, belka nawigacyjna itp. System szablonów Django powinien sprawić łatwym magazynowanie elementów w jednym miejscu, eliminując duplikaty kodu.
\nTo jest filozofia przemawiająca za template inheritance.
\nSystem szablonów nie powinien być projektowany tylko jako generator kodu HTML. Powinien być równie dobry w generowaniu innych formatów bazujących na tekście lub po prostu zwykłym tekście.
\nUżycie silnika XML do prasowania szablonów wprowadza nowy świat błędów ludzkich w edycji szablonów – i stwarza nieakceptowalny poziom narzutu w przetwarzaniu szablonu
\nSystem szablonów nie powinien być zaprojektowany w taki sposób by szablony ładnie wyświetlały się w edytorach WYSIWYG takich jak Dreamweaver. To jest zbyt dużym ograniczeniem i uniemożliwiłoby składni bycie tak ładną jak jest teraz. Django oczekuje od twórców szablonu łatwości edytowania bezpośrednio HTMLa.
\nSystem szablonów nie powinien robić cudów z białymi znakami. Jeśli szablon zawiera biały znak, system powinien potraktować ten znak tak jak traktuje tekst - po prostu go wyświetlić. Każdy biały znak, który nie jest w znaczniku szablonu, powinien być wyświetlony.
\nCelem jest to, by nie wymyślać języka programowania. Celem jest, by zaoferować na tyle programistyczno-podobnej funkcjonalności, takiej jak branching czy pętle, na ile jest to niezbędne do tworzenia decyzji związanych z prezentacją. Django Template Language (DTL) próbuje uniknąć zaawansowanej logiki.
\nSystem szablonów Django rozpoznaje szablony częściej pisane przez projektantów a nie programistów. W związku z tym nie powinien przyjmować wiedzy o Pythonie.
\nSystem szablonów, w oryginale, powinien zabraniać wstawiania złośliwego kodu - takiego jak komendy usuwające rekordy w bazie danych.
\nTo kolejny powód, dla którego system szablonów nie zezwala na standardowy kod w Pythonie.
\nSystem szablonów powinien rozpoznawać że zaawansowani twórcy szablonów mogą chcieć rozszerzyć tę technologię.
\nTo jest filozofia stoją za wyspecjalizowanymi tagami szablonów i filtrami.
\nPisanie widoku powinno być tak proste jak pisanie funkcji w Pythonie. Developerzy nie powinni być zmuszeni do tworzenia klasy, kiedy wystarczy tylko funkcja.
\nWidoki powinny mieć dostęp do obiektów zapytań - obiektów, które przechowują metadane o obecnym zapytaniu. Obiekt powinien być przekazywany bezpośrednio do funkcji widoku, nie powinna ona musieć korzystać z danych zapytania przez globalną zmienną. To czyni testowanie widoków przez przekazywanie ‚fałszywych’ obiektów zapytań lekkim, łatwym i przyjemnym.
\nDla widoku nie powinno mieć znaczenia jakiego systemu szablonów używa developer - ani czy w ogóle używa jakiegoś systemu szablonów.
\nGET i POST są rozłączne; programiści powinni wprost użyć jednego lub drugiego. Framework powinien umożliwiać łatwe rozróżnienie między danymi pochodzącymi z GET lub POST.
\nGłównymi celami Django cache framework są:
\nPamięć podręczna powinna być szybką jak tylko to możliwe. Stąd też, cały kod frameworka otaczający backend pamięci podręcznej powinien być ograniczony do absolutnego minimum, w szczególności w przypadku metody get()
API pamięci podręcznej powinno zapewniać spójny interfejs w zróżnicowanych pamięciach podręcznych backendów.
\nAPI pamięci podręcznej powinno być rozszerzalne na poziomie aplikacji zależnie od potrzeb developera (dla przykładu, zobacz Cache key transformation).
\n