Jog Jajcusia

Pythonowe frameworki...

10 października 2005 14:31:00 | kategorie: oprogramowanie, programowanie, python,

(wpis z wczoraj)

Pierwszy Pythonowy framework dla aplikacji webowych jaki poznałem to był Zope 2. Potrzebne mi było coś takiego do stworzenia interfejsu użytkownika dla naszego systemu zarządzania siecią. W PHP babrać się nie miałem zamiaru, a robienie całości jako CGI to byłaby mordęga. Padło na Zope'a, nic innego nie było, a przynajmniej nic na tyle popularnego, żeby obiło mi się o uszy. Zope, z jednej strony potężna maszyna, z drugiej wkurzające monstrum. W szczególności, że źle się za niego zabrałem. Wszystkie szablony robiłem w DTML (bo wyczytałem w ZopeBook, że równie dobrze jak ZPT, a dla programistów nawet lepsze), a cały kod rozwijałem through the web, a więc to było bardziej skryptowanie a'la PHP, niż poważne tworzenie aplikacji. W końcu przekonałem się do ZPT (bardzo porządny język szablonów, pozwalający w miarę dobrze oddzielać logikę od prezentacji i utrudniający tworzenie niepoprawnego XHTML), ale kod dalej rozwijany jest TTW, bo zmiana tego, to byłoby pisanie aplikacji (sporej już) od zera.

Widząc słabości Zope zacząłem się rozglądać za alternatywami. Żeby alternatywę poznać to trzeba spróbować, postanowiłem więc pobawić się czymś innym. Po wstępnym rozpoznaniu tego co jest na rynku, postanowiłem spróbować od CherryPy. Próba polegała na przeportowania mojego generatora i przeglądarki statystyk dla Joggera (ta czerwona kropa poniżej) na ten framework. Wcześniej to było zrealizowane w postaci skryptów CGI z prymitywnymi printami. Zrezygnowałem z języka szablonów wbudowanego w CherryPy, bo znając ZPT nie chciałem się babrać w czymś nie opartym o XML (nie pilnującym składni generowanego kodu), użyłem więc SimpleTAL. Sportowałem tak dużą część tego generatora statystyk, z błędami i dałem sobie spokój (zająłem się innymi rzeczami). CherryPy na początku zrobiło niezłe wrażenie jak prosto się w tym aplikację WWW buduje, a potem okazało się raczej prymitywne. Architektura CherryPy wręcz wymuszała bałagan, zamiast porządkować kod (to IMHO jedna z funkcji frameworków) — na dłuższą metę reprezentacja hierarchii URL poprzez atrybuty obiektów to niezbyt dobry pomysł. Do tego stan aplikacji (aktualne żądanie, odpowiedź, etc.) trzymany w zmiennej globalnej (i dostępny przez tę zmienną)... wiem że to działa, ale wydaje się niezbyt eleganckie. Krótko mówiąc CherryPy mnie nie zachwycił.

Kolejny był Nevow, oparty o Twisteda. Od początku wydawał się bardziej skomplikowany niż CherryPy. Ale po doświadczeniach z prostotą (prymitywizmem) CherryPy to mnie nie zrażało. Nevow intensywnie korzysta z interfejsów i adapterów (jak się później okazało, zapożyczonych od Zope3), ma własny, ciekawy język szablonów — oparty o XML i jeszcze bardziej niż ZPT oddzielający prezentację od logiki (w szablonach nie ma nawet pętli). Portowanie prostego CGI do Nevowa to była droga przez mękę, bo trzeba było się nauczyć nowego, skomplikowanego narzędzia. Niektóre rzeczy w tym frameworku okazywały się ostatecznie proste i logiczne, przy innych trzeba było się nakombinować. Doprowadziłem conieco (prezentację listy wejść) do działania, ale nie rozwiązałem wszystkich problemów i walka z Nevow mi się znudziła. Ostateczne wrażenie raczej pozytywne, chociaż miejscami było pod górkę. Doceniłem też wsparcie na IRCu.

Jakiś czas temu na grupie pl.comp.lang.python przeczytałem sporo dobrego o Zope3. Wtedy to było jeszcze eksperymentalne Zope-X3. Framework przepisany od zera, docelowo mający zapewniać częściową kompatybilność wstecz (czy raczej wsparcie dla portowania starych aplikacji) z Zope2. Co do tego że Zope należało przepisać od zera, nie miałem wątpliwości. W to, że w Zope krył się potencjał też. Więc, gdy pojawiły się release candidate Zope 3.1, postanowiłem spróbować. Poczytałem dokumentację, zacząłem łapać o co w tych interfejsach i adapterach (dużo intensywniej używanych niż w Nevow) chodzi i zabrałem się za portowanie statystyk. Znowu początki były ciężkie, ale prawie na każdy problem Zope oferował jakieś fajne rozwiązanie. Wszystko w postaci przejrzystego obiektowego podejścia. W przeciwieństwie do takiego CherryPy Zope3 zachęca do porządku i przemyślenia co jest obiektem, co jego prezentacją. Daje potężne mechanizmy kontroli dostępu, bezpieczeństwa kodu, i18n, skórkowania, tworzenia i walidacji formularzy i wielu innych rzeczy które w aplikacji są potrzebne. Jest to architektura i zestaw narzędzi, czyli to czym framework powinien być. I się sprawdza. Dzisiaj skończyłem portowanie statystyk i efekt jest lepszy niż oryginał, a ewentualny dalszy rozwój będzie banalnie prosty (prostszy niż w przypadku CGI).

Już po rozpoczęciu swojej zabawy z Zope3 stwierdziłem, że warto to zastosować w firmie zamiast Zope2. Większość systemu (interfejs administratora, serwisu, BOKu) zostanie na starym Zope'ie, bo przepisanie tego to znowu byłoby wiele miesięcy, ale już interfejs użytkownika końcowego robię na Zope3. Tego jest niewiele i i tak muszę to przepisać od zera. Obie części komunikują się przez bazę danych i chodzą na różnych maszynach, więc zastosowanie dwóch Zope'ów nie jest problemem. Mam nadzieję, że tej decyzji nie będę za jakiś czas żałował, jak tego, że wpakowałem się z Zope2 i aplikację rozwijaną TTW. No i to, że w ogóle wpakowałem się w kodowanie zamiast adminowania...

Jest jeszcze wiele innych frameworków i, do tego, ciągle powstają nowe. Części w ogóle nie znam, o części poczytałem w sieci i zrezygnowałem, bo ich założenia mi nie pasowały. Niektóry zdawały się zbytnio iść w kierunku PHP, którego przecież celowo unikam, inne miały jakąś dziwną architekturę, np. Webware składające się z iluś komponentów, w których nie udało mi się ujrzeć spójnej całości. Ciekawe co wygra — na świecie i wśród moich narzędzi.