Jarosław Zabiełło - BLOG: Category Django

Skype3 i polski czat dla Railsów, Django i Pylonsa

Jarosław Zabiełło — Fri, 15 Dec 2006 00:48:00 +0100

Nowy Skype 3 wprowadza małą rewolucję w stos. do poprzedniej wersji. Można nie tylko rozmawiać, ale pograć w szachy, kółko i krzyżyk i inne gry (są b. ładnie zrobione we Flashu 9). Można nagrywać rozmowy na dysk. Można tworzyć publiczne czaty. I właśnie w tej sprawie piszę ten tekst bo stworzyłem polski czat dla miłośników frameworków Ruby on Rails, Django i Pylons. Wygodniej jest czasem skonsultować coś w czasie rzeczywistym niż na grupie czy forum dyskusyjnym.

Nginx - Apache killer

Jarosław Zabiełło — Wed, 08 Nov 2006 00:47:00 +0100

W ostatnim artykule (Railsy: Lighttpd czy Apache 2.2.x?) porównywałem najbardziej popularne serwery HTTP dla Railsów. Zaintrygowany paroma wpisami w blogu postanowiłem przyjrzeć się dosyć mało znanemu serwerowi HTTP który zaczyna zdobywać coraz więcej uwagi na Zachodzie. Chodzi o ultraszybki serwer nginx napisany przez rosyjskiego programistę Igora Sysojewa.

Na pierwszy bój poszedł prosty test wyświetlenia “Hello World!” Na używanym przeze mnie serwerze dedykowanym (Athlon 64 3000+, 1GB RAM, Linux Ubuntu 64bit) dla 100 tys. zapytań (musiałem użyć aż tyle, bo serwer jest za szybki na mniejszą liczbę zapytań) uzyskałem następujące wyniki (dla polecenia “ab -n 100000 -c 1 http://localhost”):

Apache 2.2.3 = 4439 req/s

Lighttpd 1.4.11 = 7150 req/s

Nginx 0.4.12 = 8700 req/s

Co prawda Nginx wykazuje miażdzącą przewagę wydajności nad Apachem ale, z racji tego, że używam Lighttpd, który co prawda odstaje od Nginxa ale nie aż tak, postanowiłem na razie zaczekać z ewentualną migracją.

Okazało się jednak, że będę musiał przeprowadzić taką migrację szybciej niż bym chciał. Coś złego zaczęło się dziać z Ligthttpd. Po paru godzinach pracy, przestawał odpowiadać na zapytania a nawet w ogóle proces znikał z pamięci. Ki diabeł? Trudno powiedzieć, nie mam czasu aby analizować dokładniej problem. Jedyne co pomagało to regularny restart Lighttpd. Trochę głupie rozwiązanie. Postanowiłem zatem zrobić wcześniejszą migrację do Nginxa. Wg statystyk Netcraftu z Nginxa korzysta już ponad 90 tys. domen. Wydaje się to wystarczającą ilością aby można było uznać ten serwer za stabilny.

Jednakże moja migracja ma pewną trudność. Używam bowiem równocześnie PHP, Django, Rails i Zope (ściślej: Plone). Czyli całkiem niezła mieszanka aplikacji. Z PHP i Railsami było najmniej problemów, bo przykłady konfiguracji są z grubsza podane w Wiki.

Z Plone było troszkę gorzej. Musiałem bowiem znaleźć odpowiednik mniej więcej takiego kodu w Apache:

RewriteRule "^/(.*)$" 
"http://88.198.15.160:6001/VirtualHostBase/http/apologetyka.com:80/app/VirtualHostRoot/$1"  [P,L]

To nie jest zwykły rewrite, to jest połączenie proxy z rewrite.

W Lighttpd (też się swego czasu namęczyłem aby to uzyskać) uzyskuje się to tak:

url.rewrite-once = (
  "^/(.*)$" => "/VirtualHostBase/http/apologetyka.com:80/plone/VirtualHostRoot/$1"
)
proxy.server = (
   "/VirtualHostBase/" => (
     ( "host" => "88.198.15.160" , "port" => 6001 ) )
)

Trochę prób i się udało. Nginx potrzebował takiego wpisu:

location / {
  rewrite ^/(.*)$ /VirtualHostBase/http/apologetyka.com:80/plone/VirtualHostRoot/$1;
}
location /VirtualHostBase/ {
  include /opt/nginx/conf/proxy.conf;
  proxy_pass http://88.198.15.160:6001;
}

Najtrudniej było z konfiguracją Django bo opisu do Django na Nginx nie ma ani w dokumentacji do Django, ani w dokumentacji do NGinxa. Zmęczony eksperymentowaniem napisałem na listę dyskusyjną Django i dostałem całkiem pożyteczną wskazówkę odnośnie strony http://www.python.rk.edu.pl/w/p/django-pod-serwerem-nginx/. Niestety miałem pecha, bo akurat trafiłem na zmianę wpisów w DNS i artykuł był niedostępny. Udało mi się na szczęście wyłuskać jego kopię z cache Googli. Autor międzyczasie podesłał mi też pliki z artykułami. Zauważyłem że napotkał pewne problemy ze zmuszeniem Django do wyświetlania statycznej treści. Trochę podłubałem w kodzie i problem rozwiązałem. :)

Zauważyłem że Django wyświetlał mi pliki statyczne w trybie debug. Wynikało to pewnie z tego, że w urls.py stosuję zawsze taki wpis:

...
if DEBUG:
  urlpatterns += patterns('',
    (r'^images/(?P<path>.*)$', 'django.views.static.serve', {'document_root': MEDIA_ROOT+'/images', 'show_indexes': True}),
    (r'^stylesheets/(?P<path>.*)$', 'django.views.static.serve', {'document_root': MEDIA_ROOT+'/stylesheets', 'show_indexes': True}),
    (r'^javascripts/(?P<path>.*)$', 'django.views.static.serve', {'document_root': MEDIA_ROOT+'/javascripts', 'show_indexes': True}),
    )

Dla trybu produkcyjnego (settings.DEBUG=False) trzeba zmusić serwer HTTP aby się zajmował plikami statycznymi. Django ma tylko przetwarzać Pythona. Mozna to zrobić np. tak:

...
location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov) {
  access_log   off; # po co mi logi obrazków :)
  expires      30d; 
}
location / {
  include /opt/nginx/conf/fastcgi.conf;
  fastcgi_pass 127.0.0.1:6002;
  fastcgi_pass_header Authorization;
  fastcgi_intercept_errors off;
}

Gdzie plik fastcgi.conf:

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

fastcgi_param  PATH_INFO          $fastcgi_script_name;

Plik startowy napisałem sobie już w Pythonie:

#!/usr/bin/env python

import os, sys, time
DEBUG = True
# All Django project are inside /home/app/django/

path = '/home/app/django'

projects = {
    'biblia' : {
        'project': 'searchers',
        'port':6002,
        'pidfile': '/var/run/django_searchers.pid',
        'children': 4,
        },
    'koran': {
        'project': 'django_project',
        'port':6003,
        'pidfile': '/var/run/django_koran.pid',
        'children': 4
        },
    }

def start(name):
    project = projects[name]['project']
    os.chdir('%s/%s/' % (path, project))
    appl = './manage.py runfcgi host=127.0.0.1'
    cmd = '%s port=%s minspare=1 maxspare=%s pidfile=%s --settings=%s.settings' \
          % (appl, projects[name]['port'], projects[name]['children'], projects[name]['pidfile'], project)
    if DEBUG: print cmd
    os.system(cmd)

def stop(name):
    pidfile = projects[name]['pidfile']
    if os.path.exists(pidfile):
        cmd = '/bin/kill -TERM %s' % open(pidfile).read()
        if DEBUG: print cmd
        os.system(cmd)
        os.unlink(pidfile)

def restart(name):
    stop(name)
    time.sleep(1)
    start(name)

if __name__ == '__main__':
    try:
        action, project = sys.argv[1], sys.argv[2]
        if action in ['start','stop', 'restart'] and project in projects:
            if action == 'start':
                start(project)
            elif action == 'stop':
                stop(project)
            elif action == 'restart':
                restart(project)
            else:
                raise IndexError
        else:
            raise IndexError
    except IndexError:
        print "Usage: %s {start|stop|restart} {%s}" % (sys.argv[0], '|'.join(projects.keys()))

Migracja się udała. Plone, PHP, Django i Rails śmigają mi teraz na ultraszybkim (i zajmującym mało pamięci!) serwerze Nginx. Acha, zapomniałem dodać: Nginx to nie tylko duża wydajność i oszczędność pamięci. Nginx ma dużo modułów. Może nie tyle, co Apache, ale znacznie lepiej niż Lighttpd.

BTW, ciekawie wygląda także serwer Cherokee. Nginx działa tylko pod systemami POSIX (Unix, MacOS-X, Linux, FreeBSD). Cherokee natomiast posiada… binarną instalację pod Windows! Ale o tym może napiszę coś innym razem. :)

Django Book

Jarosław Zabiełło — Wed, 01 Nov 2006 10:07:00 +0100

Zgodnie z wcześniejszymi zapowiedziami, autorzy Django postanowili nie tylko napisać książkę na temat swego frameworka, ale także udostępnili za darmo książkę w wersji online . Nowo powstająca książka jest dostępna pod adresem http://www.djangobook.com. Każdy paragraf można komentować. Wersja papierowa ma być wydana w 2007 przez wydawnictwo Apress.

Django, Rails i współdzielenie danych

Jarosław Zabiełło — Wed, 19 Jul 2006 21:22:00 +0200

Osoby mające wcześniej do czynienia z innymi frameworkami, gdy sięgną do Django mogą być trochę zdezorientowane sposobem w jaki należy przekazywać zmienne do wspólnych części serwisu. Aby lepiej zrozumieć problem, podam wpierw jak jest on rozwiązywane w Railsach.

Otóż, Railsy zakładają, że każdy kontroler dziedziczy po wspólnym kontrolerze zwanym ApplicationControler. A że jest to normalna klasa Rubiego, więc nic dziwnego, że wszelkie jej metody i zmienne (instancji) są automatycznie dziedziczone we wszystkich jej klasach potomnych. To bardzo intuicyjne rozwiązanie. Jeśli chcemy przekazać jakieś wspólne dane do wszystkich kontrolerów i ich szablonów, wystarczy te dane zdefiniować w tym miejscu. Weźmy np. poniższy kod.

# plik: app/controllers/application.rb
class ApplicationController < ActionController::Base
  before_filter :defaults
  def initialize
    @name = "Jarek"
  end
  def defaults
    @msg = "Hello!"
  end
end

# plik: app/controllers/home_controller.rb
class HomeController < ApplicationController 
end

# plik: app/controllers/about_controller.rb
class AboutController < ApplicationController 
  def index
    @dodatkowa = "wartość"
  end
end

Zakładając, że nie zmienialiśmy domyślnego działania resolvera adresów URL, wpisanie strony http://localhost:3000/home wywoła domyślną metodę index() z klasy HomeController. Jeśli jej nie ma (jak na naszym przykładzie), to Rails zakłada, że chcemy wywołać jej szablon tak, jakby ta metoda istniała. Wczytywany jest zatem plik app/views/home/index.rhtml. Dzięki temu, że w klasie ApplicationController zdefiniowaliśmy 2 zmienne instancji (@name i @msg) automatycznie są one dziedziczone przez klasę HomeController i tym samym dostępne w w/w szablonie. Identycznie będzie z drugą klasą, jej szablon również będzie miał obie, zdefiniowane wyżej, zmienne¹.

W wypadku Django, sprawy wyglądają inaczej dlatego, że kontrolery³ nie są metodami klas Pythona! Są one metodami modułu Pythona. Co prawda moduł też jest obiektem, ma własną przetrzeń nazw itp. ale posiada jedną zasadniczą różnicę wobec klasy – nie można dziedziczyć modułu od modułu. Tym samym próba współdzielenia zmiennych musi być zrobiona zupełnie inną metodą.

Trochę z tym problemem się męczyłem, bo w dokumentacji mało na ten temat piszą. Dopiero na IRC podsunięto mi link do artykułu Django tips: Template context processors, który wszystko ładnie wyjaśnił². Okazuje się, że jest kilka sposobów rozwiązania tego problemu. Napisanie własnego MiddleWare (ech, nie chciało mi się, to armata na muchę), napisanie własnego znacznika dla szablonów (w wypadku mojej małej aplikacji, to też byłaby przesada) lub wykorzystanie tzw. procesora kontekstu (Context Processor). I to było to!

Wystarczy stworzyć sobie plik (o nazwie np. context_processors.py) z funkcjami implementującymi to, co chcemy wrzucić do wszystkich szablonów.

def name(request):
  return 'Jarek'

def msg(request):
  return 'Hello!'

Następnie trzeba dodać w settings.py informację że będziemy tego używać:

TEMPLATE_CONTEXT_PROCESSORS = (
  'myapp.context_processors.name',
  'myapp.context_processors.msg',
  )

W wypadku generic views to wszystko, bo one automatycznie wciągają RequestContext dla swoich szablonów. W wypadku naszych kontrolerów (zakładając, że używamy render_to_response() aby wyświetlać szablon) trzeba na końcu metody render_to_response() dodać jeden parametr ‘context_instance’. Czyli:

# wpierw wciągamy RequestContext
from django.template import RequestContext

def home(request):
  return render_to_response(
    'home.html', 
    context_instance=RequestContext(request))

def about(request):
  return render_to_response(
    'about.html', 
    {'dodatkowa': 'wartość'},
    context_instance=RequestContext(request))

Tak coraz bardziej wgłębiając się w Rails i Django widzę, że Rails jest jednak bardziej intuicyjny i łatwiej się go nauczyć. Jednakże Django wydaje się mieć sporo potężnych mechanizmów, których odkrywanie (mam nadzieję) się uprości jak tylko jego twórcy opublikują pierwszą książkę na jego temat (ma być dostępna także w wersji online za darmo!)

¹ W podanym wyżej przykładzie wykorzystałem dwa różne sposoby przekazania zmiennych. Za pomocą konstruktora i za pomocą metody ‘before_filter’. Wiadomo, że konstruktor nie nadaje się do przekazywania wszystkiego. Czasami musimy przekazać coś, co istnieje już po wywołaniu konstruktora. Wtedy przydaje się metoda ‘before_filter’. To jedna z wielu sztuczek jakie ma w swym arsenale Rails aby kod był czysty, klarowny i zgodny z zasadą DRY (nie powtarzania się).

² Zobacz też artykuł How Django processes a request?.

³ W Django nazywane są one metodami widoku. Osobiście nie podoba mi się zamieszanie terminologiczne jakie Django zrobiło z modelem MVC. Kontroler to dla nich Widok (View), zaś Widok to Szablon. Trochę to bez sensu, bo nikt tak tych rzecz nie nazywa. Czyli djangowe metody widoku to nic innego jak akcje kontrolera dla Rails i reszty świata.

Django i Rails biją PHP

Jarosław Zabiełło — Fri, 14 Jul 2006 17:34:00 +0200

Porównanie wydajności trzech frameworków: Symfony, Ruby on Rails i Django pokazuje że Rails jest znacznie szybszy od pehapowego Symfony, a Django znacznie szybszy od Railsów. Co ciekawe, PHP5 używał akceleratora.

Django i jego konkurenci

Jarosław Zabiełło — Wed, 21 Jun 2006 17:18:00 +0200

Po ostatnich paru tekstach o Django, pora na odrobinę odmiany, bo Django niekoniecznie musi być uważany za najlepszy framework w klasie środowisk “railsopodobnych”. :)

TurboGears

Trzeba pochwalić dobry marketing megaframeworku¹ TurboGears, bo już w Amazonie jest nawet dostępna książka na jego temat. Jednakże, małe to pocieszenie. TurboGears raczej nie będzie poważną alternatywą dla Django z prostej przyczyny. Cały jego kręgosłup opiera się na mało profesjonalnej implementacji frameworka CherryPy. Na ten temat było sporo dyskusji na grupie pl.comp.lang.python, więc nie będę się powtarzał.

Pylons

O Pylons pisałem wcześniej ale nie w kontekście Django. Moim zdaniem, Pylons jest jedynym frameworkiem, który aktualnie może stanowić być realną alternatywę dla Django.

Wpierw trzeba napisać kilka słów wyjaśnienia dla tych, co myślą że Pylons to jakiś taki zlepek innych bibliotek i frameworków jak TurboGears. Pylons to właściwie nic innego jak framework Myghty tylko, że ze znacznie większym przełożeniem akcentów na paradygmat MVC i podobieństwo do będacych aktualnie “na fali” Railsów.

Twórcy Myghty, mimo bardzo dobrej implementacji i wydajności nie mogli wcześniej przebić się do miłośników Pythona ze względu na zbytnie podobieństwa do Perla (nic dziwnego, Myghty był wzorowany na bardzo dobrym perlowym Masonie, który jest używany na dosyć dużą skalę)

Postanowiono więc troszkę dostosować Myghty dla ludzi lubiących prostotę Pythona i elegancję Ruby on Rails. I tak powstał Pylons.

Zalety Pylonsów.

Myghty pozwala praktycznie na wymianę wszystkich swoich “podzespołów”. W wypadku Pylonsów, użyto resolvera adresów URL opartego na bibliotece Routes. W skrócie można powiedzieć, że Pylons jest tu prawie identyczne jak Rails. “Prawie”, bo Routes jest potężniejszym resolverem od tego co mają Railsy (pozwala np. na używanie większych uogólnień i wyrażeń regularnych).

Elastyczność

Elastyczność Pylonsów jest znacznie większa od Django. W praktyce tam, gdzie stosuje się wstawki PHP do profesjonalnych systemów CMS takich jak RedDot, Pylons dzięki swojej elastyczności i potędze szablonów Myghty znacznie łatwiej może wyprzeć tu PHP. Django jest systemem znacznie bardziej monolitycznym. To jest jego zaletą ale równocześnie także i wadą w wypadkach kiedy potrzebujemy znacznie większej elastyczności.

DRY w kontekście generowania adresów URL

Przewagą korzystania z Routes jest nie tylko prostota budowania adresów url bez konieczności posiadania wiedzy o wyrażeniach regularnych. Największą zaletą jest stosowanie helperów do budowania adresów URL. Identycznie jak w Railsach, jakakolwiek zmiana zasady rozwiązywania adresów, automatycznie przemapuje wszystkie adresy http we wszystkich szablonach. W wypadku Django musimy mozolnie poprawiać wszystkie szablony. W wypadku dużego serwisu jest to kupa, niepotrzebnej roboty².

Ajax i cała reszta helperów z Ruby on Rails.

Django (jak dotąd) nie posiada wbudowanej implementacji Ajax’a. Nie ma nawet jednomyślności jaką bibliotekę do tego celu mieliby użyć³. Poza tym Pylons implementują wiele z helperów jakie mają Rails dostępne dla swoich szablonów.

Potęga szablonów Myghty

Jeśli komuś przeszkadzają małe możliwości szablonów Django (celowo takie są, bo są kierowane do nieprogramistów) to możliwości jakie dają szablony Myghty są po prostu powalające. Jeśli ktoś mówi, że Django ma dobry cache, to niech się przyjrzy temu co potrafią wykorzystywane w Pylons – szablony Myghty.

Każdy szablon może być komponentem niezależnie keszowanym wg bardzo wyrafinowanych zasad (potężniejszych od tych, co oferuje Django) Regeneracja cache jest także inteligentnie napisana (podobnie jak to robi Skunkweb) Tzn. nigdy nie ma sytuacji, kiedy nadchodzi żądanie wyświetlenia strony i w tym samym momencie trzeba odświeżyć cache (bo się np. przeterminował). Pylons w takim wypadku, odwleka operację odświeżania cache’a i podaje starą zawartość. Regeneracja następuje zaraz za tym requestem. W efekcie nigdy nie ma żadnych “czkawek” w takiej krytycznej sytuacji.

Jeśli ktoś myśli, że to bardzo rzadki przypadek, to niech sobie wyobrazi czy co się dzieje w wypadku naprawdę dużego obciążenia serwera. Pylons/Myghty był od początku tworzony z myśla pracy w sytuacji mocno obciążonego serwera.

Szablony Myghty obsługują nie tylko bardzo potężne mechanizmy includowania (tzn. można przekazać wiele różnych parametrów do includowanego szablonu włącznie z indywidualnymi zasadami keszowania). Myghty obsługują także mechanizm dziedziczenia⁴.

Automatyczne generowanie dokumentacji.

Pylonsy pozwalają na automatyczne generowanie dokumentacji z projektu. Wykorzystuje do tego celu pythonowe docstringi i zamiast HTML – reStructuredText (które są częścią projektu docutils)

Zapakowanie projektów do uniwersalnego formatu .egg.

Pylonsy potrafią zapakować cały projekt do paczki .egg co umożliwia bardzo łatwą dystrybucję aplikacji pylonsowych. Django tej (jakże pożytecznej) opcji w ogóle nie ma zaimplementowanej!

Zalety Django.

Mimo powyższych zalet Pylonsów, Django ma także kilka swoich, dobrych stron.

Lepsza dokumentacja.

Dzięki swojej monolityczności, Django dysponuje znacznie pełniejszą dokumentacją i jest ona zgromadzona w jednym miejscu. W wypadku Pylonsów dokumentacja jest niezbyt wyczerpująca i porozrzucana. Wynika to w głównej mierze z tego, że Pylons używa gotowych komponentów z innych projektów.

Świetna obsługa formularzy.

Django pracuje na wyższym poziomie abstrakcji odnośnie pracy z formularzami. O ile nie potrzebujemy większej elastyczności, to tą kwestię mają doskonale zaprojektowaną. Jeśli chcemy czegoś więcej, możemy przeciążyć metody jakie używa Django i wzbogacić je w dodatkowe opcje (np. obsługę zdarzeń javascript). Django obsługuje bardzo elegancko walidację formularzy. Pylons TurboGears też) korzysta z FormEncode, ale wydaje mi się, że Django jest tu jeszcze prostsze.

ORM

Djangowy korzysta z własnego ORM (mapera relacyjno-obiektowego) Pylons korzysta z SQLObject. Oba ORM’y są podobne, ale mnie się bardziej podoba ten, co ma Django. Moim zdaniem ma bardziej elegancką składnię. Ma także lepszą dokumentacje. Trochę to dziwne, bo SQLObject nie jest wcale nowym projektem. Mogliby się postarać o lepszą dokumentację, bo ta co jest, jest fatalna.

Panel admina.

To jest wizytówka Django. O ile nie potrzebujemy bardzo specyficznego jego działania, to jest bardzo pomocny. To nie jest żaden “scaffolding” z Railsów. To dopracowana aplikacja końcowa.

Generic views

To kolejna wizytówka Django. Za pomocą konfiguracji adresów (w pliku urls.py) i generic views można budować całe serwisy bez tworzenia ani jednego kontrolera. W ten sposób działa cała strona domowa Django. Osobiście głęboko nie wchodziłem w działanie tych mechanizmów, ale wyglądają bardzo interesująco i mogą daćo gromne przyśpieszenie w budowaniu stron www.

Szersze wdrożenia i silniejsze wsparcie komercyjne.

Django może się poszczycić niezła listą poważnych wdrożeń. Skala złozoności portalów zbudowanych w Django przewyższa to, czym się chwali strona domowa Railsów. Jeśli chodzi o Pylons, to wdrożeń jest bardzo mało. Może brakuje im trochę zmysłu marketingowego jaki mają twórcy Railsów i Turbogears? Na pewno brakuje lepszej, obszerniejszej dokumentacji wraz z większą ilością przykładów.

Na bazie Django oferowany jest także odpłatnie, komercyjny CMS (system zarządania treścią) – Ellington. Specjalizowany jest do większych serwisów, gazet itp. Firmy ceniące sobie wsparcie komercyjne, nie muszą się więc obawiać, że Django to jakiś projekt paru zapaleńców.

Django w rzeczy samej, jest projektem który został wyekstraktowany z komercyjnego projektu Ellington.

No i na koniec, last but not least, twórcom Django udało się pozyskać sympatię samego twórcy języka Pythona – Guido van Rossum’a. Na stronie głównej. Pythona w sekcji Web programming, obok Zope widzimy Django i Turbogears…

Podsumowanie.

Django ma swoje zalety, ale nie jest wolny od wszelkich wad. Jednakże, ogólnie rzecz biorąc, to dobry framework, który raczej nie powinien mieć trudności w zdominowaniu dziedziby budowania aplikacji internetowych w Pythonie.

Jednak tam, gdzie liczy się większa elastyczność i gdzie monolityczność Django jest nie do zaakceptowania, głównym moim faworytem jest Pylons. To jedyna realna alternatywa dla Django⁵.

¹ Megaframework – środowisko zbudowane z gotowych, innych rozwiązań. Turbogears korzysta m.in. z frameworku CherryPy, szablonów Kid, SQLObject jako ORM (mapera relacyjno obiektowego).

² Developerzy Django są przyciskani do muru żądaniami aby wprowadzić jakiś mechanizm zastępujący ręczne wpisywanie adresów, i nie wykluczają, że użyją Routes jako alternatywnego resolvera URL. Ale nie wiadomo kiedy i czy w ogóle to zrobią.

³ Nie wiem dlaczego nie chca użyć gotowych bibliotek jakie już używa Pylons. Po co odkrywać na nowo koło?

⁴ Dziedziczenie działa trochę inaczej niż w Django i Cheetah. Np. nie ma tu, tak wygodnych “bloków” do przeciążania. Ale jest za to coś, co przypomina “akwizycję” znaną z Zope. Tzn. w Myghty można wrzucić do folderu z szablonami plik “autohandler” i automatycznie staje się szablonem bazowym dla wszystkich szablonów (bez dotykania ich zawartości!) To pozwala na wygodne zarządzanie całymi grupami szablonów.

⁵ Poza oczywiście Zope czy Plone, ale to jest trochę inna bajka i temat na oddzielne rozważania. :)