Jarosław Zabiełło - BLOG: Django - zabójcza aplikacja. Część II.

Django - zabójcza aplikacja. Część II.

Jarosław Zabiełło — Sat, 27 May 2006 18:53:00 +0200

Jak wspomniałem w pierwszej części, Django jest frameworkiem który wyrósł na bazie zastosowań komercyjnych. Zanim twórcy zdecydowali się otworzyć i udostępnić jego kod na zasadach open-source, Django był już wcześniej intensywnie używany w zastosowaniach komercyjnych¹.

Przewaga Django

Wcześniej pisałem o zaletach Pylonsów. Jednakże, po moich ostatnich testach z “oczyszczoną z magii” wersją Django muszę przyznać, że jest to chyba aktualnie najlepszy framework, z jakim miałem do czynienia w tej klasie zastosowań.

Django oferuje znacznie więcej helperów i udogodnień niż świetny Pylons. Poza wbudowaną autoryzacją i zaawansowanym panelem admina, Django pracuje na wyższym poziomie abstrakcji niż Pylons czy Rails. Zamiast prostych generatorów HTML dla formularzy, Django wprowadza kontrolki, które pracują na wyższym poziomie abstrakcji. Bardzo przejrzyście obsługuje także walidowanie formularzy. Kto się męczył z obsługa formularzy, nareszcie odetchnie z ulgą. Idea manipulatorów bardzo upraszcza pisanie obsługi formularzy. Ktoś powie, że to można sobie samemu napisać. Owszem. Ale Django daje ci to już gotowe. Uruchamiasz i używasz zamiast tracić czas.

Sprawa dokumentacji, i promocji w ogólności, w wypadku wiekszości frameworków Pythona jest po prostu żenująca. Zdumiewające jest jak to jest możliwe, że nawet tak potężne środowisko jakim jest Zope ma tak słabą stronę i chaotycznie porozrzucaną dokumentację.

Kilka mądrych posunięć.

Pierwszą, mądrą rzeczą, jaką zrobiono po otwarciu kodu Django, było skupienie się na pisaniu dokumentacji. Dzięki temu, Django ma dziś jedną z najlepszych dokumentacji pomiędzy pythonowymi frameworkami. Bez dobrej dokumentacji, trudno aby ktokolwiek się zainteresował projektem. Dokumentacja Django nie równa się jeszcze temu co jest dostępne dla Railsów ale jest i tak lepsza od większości frameworków pythonowych.

Drugim, równie dobrym posunięciem, był refaktoring pierwotnego kodu zgodnie z zasadami filozofii Pythona. Wg zasady, ze działanie jawne jest lepsze od domyślnego, nastąpił proces usuwania “magii” z kodu. Np. teraz zamiast tajemniczych prefiksów do nazw dodatkowych metod modelu, można tworzyć je bardziej naturalnie – jako metody klasowe Pythona. Aktualnie wersja pozbawiona “magii” jest dostępna w repozytorium SVN. Frameworkiem, który jest mocno przeładowany “magicznymi” metodami jest Rails. Może to i ładnie wygląda, ale filozofia Python potępia takie podejście, gdyż to utrudnia programiście w szybkim zorientowaniu się o co chodzi w kodzie.

Trzecim, dobrym pomysłem, jest możliwości testowania środowiska w sposób interaktywny w interpreterze. Domyślne uruchomia się to w miejscu stworzonego projektu za pomocą komendy: manage.py shell. Ta komenda odpala ipythona (ile mamy go zainstalowanego) i udostępnia w nim łatwy dostep do całego środowiska Django, jego modeli, bibliotek itp. Ipython to podrasowana wersja interpretera Pythona. Świetnie uzupełnia metody, ma dobrą historię edycji i cały szereg dodatkowych możliwości².

Przykładem różnic w podejściu do kwestii jawności i “magii” jest inny sposób podejścia do modułów i przestrzeni nazw między Pythonem a Ruby. Python stosuje przejrzystą do bólu zasadę: moduł to po prostu plik. Wszystko co w nim jest, automatycznie jest ładowane do przestrzeni nazw określonej nazwą pliku. Python umożliwia także selektywne ładowanie z modułu wybranych klas i metod. Wszystko jest niezmiernie czytelne.

W wypadku Rubiego mamy tylko wyrażenie require które odpala i włącza plik. Przy czym z tego kodu kompletnie nic nie można wywnioskować, nawet tego, czy w środku zawiera jakikolwiek moduł. Trzeba zajrzeć aby się dowiedzieć, co zostało dorzucone do naszej przestrzeni nazw. Pythonowa zasada “jawności ponad domyślaniem się”, w tym wypadku stanowi kolejny argument na rzecz większej produktywności Pythona wobec Rubiego.

Django jest szybsze.

Django jest cholernie szybkie. Nie tylko dlatego, że korzysta z Pythona i bytecodu, ale także dlatego, że jest dobrze napisane. Np. szablony Django są szybsze od Cheetah i nie wymagają żadnej dodatkowej kompilacji! Wszystkie wyrażenia regularne używane np. do parsowania adresów URL są jednokrotnie kompilowane, są więc wykonywane bardzo szybko. Mało tego, w Django można włączyć obsługę akceleratora Psyco. Wystarczy w mojprojekt/settings.py dodać linijkę ENABLE_PSYCO = True. Railsy nie mają wydajnościowo szans z Django. Chyba tylko Pylons może się zbliżyć i nawiązać jakąś walkę na tym polu. Rails i PHP są tu bez szans.

Django pracuje na wyższym poziomie abstrakcji.

Obsługa formularzy, ich walidacja są zwykle uciążliwe i programiści mają z nimi ciągle do czynienia. Rails oraz Pylons (który to skopiował z Railsów) udostępniają cała grupę wygodnych helperów do generowania kodu html np. do formularzy. Mimo, że to jest na pewno lepsze podejście od bezpośredniego dłubania w kodzie HTML, to Django oferuje coś znacznie lepszego – kontrolki. Coś, co używa np. ASP.NET, tylko że znacznie prostsze w obsłudze.

Djangowe modele korzystające z mapowania relacyjno-obiektowego (ORM) również pracują na wyższym poziomie abstrakcji niż tylko odwzorowania prostych typów danych jakie posiada relacyjna baza danych. Uważam też, że djangowy ORM jest lepszy od SQLObject. Nie dość że ma znacznie lepszą dokumentację, to na dodatek ma więcej możliwości. Np. niby taka trywialna sprawa, ale jak w SQLObject odwzorować takie zapytanie (z takim samym traktowaniem dużych i małych polskich znaków)?

SELECT * FROM tabelka WHERE pole LIKE '%wartość%'

W Django to jest trywialna operacja i na dodatek operuje na generatorze:

for row in Tabelka.objects.filter(pole__icontains="wartość"):
    print row.pole

W kolejnych częściach, zajmę się przykładem stworzenia prostej aplikacji internetowej. Pokażę też jak przeciążyć modyfikator pluralize aby uwzględniał polskie znaki, i jak obsługiwać formularze (włącznie z dynamicznym budowaniem ich treści)

¹ Poza całym szeregiem złożonych portali, developerzy Django sprzedają Elington – profesjonalny CMS zbudowany na bazie tego frameworku. Oczywiście Railsy również powstały pierwotnie jako projekt do zastosowań komercyjnych. Stąd nic dziwnego, że oba środowiska oferują sporo interesujących rozwiązań.

² Aby działały uzupełniania metod (po wciśnięciu klawisza Tab) trzeba doinstalować moduł readline oraz ctypes. Jeśli interpreter nie wyrzuca wyjątku po wpisaniu import readline, to znaczy że mamy go już zainstalowanego.

(Zobacz: część III)

"Django - zabójcza aplikacja. Część II." by Jarosław Zabiełło

Wed, 22 Nov 2006 00:57:26 +0100

Kontrolki Django wyglądają bardzo prosto w szablonie. Wg mnie te dostarczane standardowo powinny być bardziej elastyczne (np. brakuje mi tam parametrów dla styli) Zawsze jednak możesz stworzyć swoje klasy na bazie podstawowych kontrolek. Wręcz to jest koniecznie dla bardziej złożonych przypadków.

Z kolei Pylons jest o tyle ciekawy, że udostępnia helpery skopiowane z Ruby on Rails, które są bardzo elastyczne. Znacznie bardziej od tych, co ma Django, ale coś za coś. Django zapewnia elegancką walidację szablonów (szablon wiąże z klasą, piszę o tym w trzeciej części artykułu o Django). Pylons do tego używa biblioteki FormEncode.

Zope to oddzielna, ciężka bestia, nie będę komentował. Powiem tylko, że tam wszystko robi się inaczej. Walidację szablonu zapewnia np. gotowy produkt Zope, który wystarczy dodać do Zope.

"Django - zabójcza aplikacja. Część II." by proximus

Sat, 18 Nov 2006 00:30:56 +0100

Witam, naprawdę świetne artykuły. Jestem raczej początkującym programistą. Mam kilka pytań odnośnie tworzenia interfejsu użytkownika w Django za pomocą opisywanych w tekście “kontrolek”. Chodzi mi o prostotę generowania dobrze wyglądających, i łatwych w obsłudze formularzy, list itp. czyli wszystkiego co wiąże się z UI. Czy Django wspiera samo z siebie tworzenie UI czy też trzeba “ostro dłubać” w htmlu i stylach? Podam przykład: chciałbym stworzyć formularz z wieloma inputami, chceckboxami itd. W jaki sposób wykonać to najłatwiej (i najszybciej) w Django tak, aby było to wygodne w użytkowaniu?(głównie chodzi o to, żeby inputy nie były każdy w innej linii, a to dlatego, żeby nie trzeba było w nieskończoność przewijać strony) Moje pytanie bierze się stąd, że w różnych tutorialach i screencastach widziałem, bardzo proste przykłady, w których formularze składały się z maksymalnie kilku pól, a interesuje mnie jak to wygląda w wersji bardziej skomplikowanej. Korzystając z wiedzy autora chciałbym zapytać także jak od strony wsparcia dla budowania UI wyglądają pylons i zope? Z góry dziękuję za odpowiedź.

"Django - zabójcza aplikacja. Część II." by Drogomir

Mon, 29 May 2006 11:48:12 +0200

Bardzo fajny tekst, czekam na dalszą część.

Odpaliłem dzisiaj django i przedzedłem przez 1 tutorial. Wygląda to dość fajnie, ale zawsze jak widzę takie narzędzia, to zastanawiam się co będzie, jak będę chciał podmienić niektóre akcje, dodać gdzieniegdzie ajax’a, zrobić jakieś niestandardowe formularze (na przykład menu w postaci drzewa) itd. Będę musiał rozpracować django w tym kierunku.

Jak na razie django w moich oczach jest doskonałym narzędziem do tworzenia raczej szablonowych aplikacji – cms’y na przykład. Czekam więc na następne artykuły, które być może będą powodem zmiany mojego zdania ;-)

"Django - zabójcza aplikacja. Część II." by Balwi

Sun, 28 May 2006 12:24:47 +0200

Szukam jakiegoś frameworka i to wygląda bardzo ciekawie czekam na więcej. Bardzo ciekawy blog, tak trzymać !!!

"Django - zabójcza aplikacja. Część II." by Adamh

Sun, 28 May 2006 10:34:01 +0200

Wiem, ze ksiazka powstaja i wiem, ze ponoc ma byc wydana na licencji FDL (odpowiednik GPL dla ksiazek) tak jak: http://diveintopython.org/ Dodam, ze bardzo na nia czekam.

"Django - zabójcza aplikacja. Część II." by Jarosław Zabiełło

Sun, 28 May 2006 09:39:38 +0200

Przemek: Django jest bardzo dobrze wytestowany głównie z PostgresSQL, na nim od początku pracował. Z kolei, mam silne wrażenie, że Rails od początku powstawał i był testowany głównie na MySQL…

Adamh: książka do Django jst w trakcie pisania przez jego twórców. Fakt, że dokumentacja Railsów wraz z książkami jest nie do pobicia. Ale ja się sam zdziwiłem jak niewiele trzeba, aby coś napisać w Django. Może dlatego, że Pythona wciąż lepiej znam i poruszam się w nim bardziej intuicyjnie niż w Ruby?

Maniel: ipython ma to wszystko już gotowe. No chyba, że coś innego masz na myśli.

"Django - zabójcza aplikacja. Część II." by Tomek

Sun, 28 May 2006 07:33:40 +0200

Dzęki bardzo – czekam na więcej bo stoje przed wyborem ruby czy python… :)

"Django - zabójcza aplikacja. Część II." by maniel

Sun, 28 May 2006 06:58:53 +0200

ja chciałem zauważyć ze standardowy interpreter pythoina tez można skonfigurować coby dopelniał nazwy klas, metod i zmiennych oraz zapisywał historię poleceń do pliku jak w shellu ;-)

"Django - zabójcza aplikacja. Część II." by Adamh

Sun, 28 May 2006 05:25:32 +0200

Tak jak pisalem juz kilka razy wczesniej. Przyszlosc WWW to imho Rails i Dajngo. Django zrobilo duzy krok do przodu i moze niedlugo nawiazac bezposrednio walke z Rails jesli chodzi o popularnosc. Z wiekszoscia argumentow jakie podajesz zgadzam sie czesciowo ale z jednym nie mozna sie spierac:wydajnosc. Poki co Django brakuje wsparcia i rozglosu, do tego dokumentacja nadal jest bardzo slawa w porownaniu do Rails (nie wspomne nawet o ksiazkach).

"Django - zabójcza aplikacja. Część II." by Przemek Piotrowski

Sun, 28 May 2006 03:10:07 +0200

Swietny artykul, nareszcie magic-removal i nareszcie obsluga Oracle. Wersja 1.0 prawdopodobnie usunie inne frameworki w cien juz na stale – Guido (=Google) popiera Django i to rowniez moze okazac sie decydujace. Szkoda tylko ze jego developerzy maja taki lekcewazacy stosunek do integracji z komercyjnymi warstwami aplikacji, ale licze ze to sie jeszcze zmieni w przyszlosci.