Django – framework dla zapracowanych programistów. Wprowadzenie

Django w wielu materiałach wymieniany jest obok najpopularniejszego w ostatnich latach frameworka – Ruby on Rails. Choć różni je język (Django – Python, Rails – Ruby), podejście do niektórych zagadnień i sposób rozbudowy, to na podstawowym poziomie oba programy starają się wypełnić to samo zadanie – dać deweloperowi narzędzie elastyczne, wygodne, szybkie i łatwe do opanowania.

Django bazuje na Pythonie – języku ogólnego stosowania, który istnieje tak długo jak Java i jest bardziej elastyczny niż PHP. To właśnie tej podstawie zawdzięcza framework przejrzystość i prostotę, pozwalającą generować kod krótki i łatwy do późniejszej analizy. Co równie istotne, Python doczekał się wielu bibliotek dodatkowych związanych nie tylko z Internetem, ale także innymi działami informatyki – obliczeniami matematycznymi czy grafiką komputerową. Znacznemu skróceniu ulega dzięki temu czas tworzenia nietypowych aplikacji – wystarczy dobrze poszukać, by stwierdzić, że rozwiązaniem naszego problemu może być stworzona już wcześniej biblioteka.

Opisując zalety tandemu tandem Python-Django, warto także wspomnieć, że stał on się standardową platformą w systemie Google App Engine, pozwalającym na tworzenie witryn internetowych bazujących na infrastrukturze Google. W Polsce Django docenił między innymi serwis społecznościowy Grono.net oraz gazeta Super Express.

Historia

Framework Django narodził się w 2003 roku w USA, gdy w internetowym dziale jednej z lokalnych gazet programiści stwierdzili, że chcą przenieść istniejące, napisane w PHP witryny na platformę języka Python. Dostępne w tym czasie frameworki, były dla nich albo zbyt rozbudowane (Zope), albo nie spełniały specyficznych potrzeb serwisu. Ponieważ dziennikarstwo to dziedzina wymagająca natychmiastowej reakcji na zmieniające się wydarzenia, nowy system musiał zapewniać tworzenie kolejnych elementów składowych nie w tygodnie czy miesiące, ale w dni i godziny. Od pomysłu do realizacji i udostępnienia użytkownikom nowego działu mijał bowiem częstokroć tylko jeden dzień.

Django nie powstawało więc jako niezależny framework – między 2003 a 2005 rokiem stanowiło część większego systemu trzech portali. Dzięki temu jego użytkownicy także obecnie mogą mieć pewność, że wszystkie proponowane rozwiązania sprawdziły się w praktyce i to w bardzo wymagającym środowisku. W 2005 roku nastąpiło wyodrębnienie rdzenia systemu i udostępnienie go na zasadach Open Source pod nazwą Django. Przez kolejne trzy lata system ulegał metamorfozie i wielu udoskonaleniom, by w 2008 roku osiągnąć status 1.0. Obecnie najnowszą wersją jest wydanie 1.1.

Elastyczny wzorzec MVC, czyli MTV

W trakcie projektowania zrębów prostej aplikacji internetowej, najczęściej nie przejmujemy się faktem, że w tym samym pliku mieszają się ze sobą dane, logika biznesowa, logika prezentacji i kod HTML. Kiedy program zaczyna się rozrastać, taki zlepek utrudnia nie tylko dalszą rozbudowę, ale także wielokrotne wykorzystanie podobnych fragmentów kodu.

Pomoc w rozwiązaniu przedstawionego problemu zapewnia podział aplikacji na logiczne elementy – nazywany skrótowo wzorcem MVC (Model-View-Controller). Ponieważ skrót MVC nie brzmiał zbyt chwytliwie, autorzy Django użyli „odmiany” o nazwie MTV (Model-Template-View). Różnice między wzorcami dotyczą z pozoru tylko szczegółów, te drobne modyfikacje mogą jednak stanowić o elastyczności całego systemu. Niezależnie jednak od nazwy, zastosowanie separacji poszczególnych warstw aplikacji ułatwia wielokrotne wykorzystanie podobnych elementów (zasada DRY), zmniejsza złożoność i upraszcza poszukiwanie kodu realizującego daną funkcjonalność (zasada KISS).

Warto przyjrzeć się bliżej, jak Django wciela w życie opisane wyżej zasady. Pierwszy komponent – modele – to klasy definiowane w języku Python, określające w czytelny sposób strukturę tabel, na podstawie której Django automatycznie generuje zapytania SQL. Te ostatnie dotyczą między innymi tworzenia samych tabel, ich edycji oraz pobierania danych. W wielu sytuacjach nie trzeba zatem w ogóle używać języka SQL, co zapewnia lepszą kompatybilność kodu (obsługę wielu systemów bazodanowych) i sprzyja zachowaniu zasady DRY.

Widoki są z kolei standardowymi funkcjami Pythona, których jedynym zadaniem jest pobieranie obiektu żądania i zwracanie obiektu odpowiedzi lub zgłaszanie wyjątku. Nie musimy więc tworzyć specjalnych klas kontrolerów (jak w modelu MVC), zastanawiać się, co ze sobą połączyć i po jakich klasach bazowych dziedziczyć. Takie podejście sprzyja więc bezpośrednio realizacji zasady KISS. Warto w tym miejscu zaznaczyć, że jeśli zajdzie potrzeba, możemy oczywiście tworzyć także odpowiednie klasy kontrolerów.

Ostatnim elementem opisanej struktury są szablony służące do generowania końcowych wyników. Zbudowano je według możliwie uproszczonego, niebazującego na języku XML schematu. Dzięki temu cała struktura jest zrozumiała zarówno dla projektantów jak i grafików oraz innych osób standardowo niezajmujących się programowaniem (zasada KISS). Jednocześnie obsługuje ona system dziedziczenia przypominający dziedziczenie klas, co minimalizuje powtórzenia kodu HTML i pomaga zastosować się do wskazówki wyrażonej akronimem DRY.