Pythonowe frameworki…

(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.

Reklamy

21 uwag do wpisu “Pythonowe frameworki…

  1. _Pythonowe_

    Właśnie doszedłem do momentu, gdy bardzo sprawnie posługuję się Pythonem. Nie mam zamiaru teraz nagle uczyć się nowego języka. Jasne, podstaw (pozwalających stworzyć właściwie cokolwiek) nauczę się w godzinkę, ale nabranie doświadczenia i wprawy jaką mam teraz w Pythonie zajęłoby pewnie lata.
    Poza tym, jakby się okazało, że Ruby bardziej mi pasuje… to by znaczyło, że lata spędzone z Pythonem zostały zmarnowane. Jeśli tak jest, to nie chcę tego wiedzieć! 😉

    Polubienie

  2. Hehe.. to faktycznie, nie ruszaj Ruby 😉 Aczkolwiek, z tego co wiem, wielu deweleperów Pythona ma duży wkład w Ruby, zatem wydaje mi się, że raczej byś pomyślał, że lata doświadczeń z Pythonem sprawiło, że jesteś teraz lata przed innymi, którzy dopiero uczą się Ruby 🙂

    Polubienie

  3. nbw: nauczenie się podstaw CherryPy, czy PHP to też momencik…

    rachwal: usłyszałem, że dobre, przeczytałem tutoriala (dołączony do pakietu z Pythonem w mojej dystrybucji)… i już nie wyobrażałem sobie pisania w czymś innym.

    Polubienie

  4. Mam Cię Jarku za mądrego i rozsądnego człowieka, ale z całym szacunkiem – w tej chwili masz problem z postrzeganiem rzeczywistości 🙂

    Coś na uspokojenie, przeczytaj raz, drugi, trzeci. Potem jeszcze raz, może "zagadaj na privia", a następnie, jeśli wciąż widzisz neofitę – wyzywaj, masz moje błogosławieństwo 🙂

    Dla ułatwienia interpretacji: do języków programowania, programów itp, podchodzę jak do narzędzi – dobieram to, w którym pracuje mi się najwygodniej i najszybciej osiągnę pożądany efekt. Bez dorabiania ideologii. Rulezizm minął mi wraz ze sprzedażą Amigi.
    Do Pythona nic nie mam – sam z niego korzystam gdy jest potrzebny.
    I jeszcze jedno – trudno korzystać z RoR więcej niż 3 lata, gdy Rails, oficjalnie, ma niewiele ponad rok. Co innego Ruby.

    Polubienie

  5. ktoś: wzorowany na jakimś Perlowym frameworku. To mnie trochę zniechęca. Pythonowcy i Perlowcy mają zupełnie różne poczucie estetyki i elegancji kodu. Plus PSP i <%python> </%python>, czyli coś jak PHP — takiego wiązania kodu Pythona z kodem HTML chcę uniknąć. Po pierwsze jest mało eleganckie i utrudnia rozdzielenie logiki od prezentacji, a po drugie nie zapewnia żadnej kontroli nad poprawnością składniową wygenerowanego kodu HTML (można postawić <p> i zapomnieć </p> i nic nam o tym nie powie). Reszta z tego co oferuje Myghty (tego co widzę pierwszym rzutem oka na dokumentaje) jest w jakiejś formie dostępna także w Nevow i Zope3.
    Po prostu Myghty to jeden z tych frameworków, które odrzuciłem na wstępie, „bo ich założenia mi nie pasowały”.

    Polubienie

  6. Jajcuś, jak Cię już trochę znam, to masz rację, że trzymasz się Pythona. Python jest dla koneserów.
    Ruby dla takich szaleńców jak ja (poprawiałeś mój kod jggtrans do swojego stylu, to wiesz co mam na myśli) – jestem nim zachwycony.

    Polubienie

  7. Bez urazy, nbw, ale najwyraźniej masz problemy z czytaniem ze zrozumieniem. Po kiego wyskakujesz z RoR, skoro Jacek napisał o szukaniu frejmwerku w Pythonie? Czy RoR jest w Pythonie?
    Tak się zachowują neofici i dla mnie nim pozostaniesz, dopóki tego nie zrozumiesz. Jak chcesz, to możesz o tym dyskutować do updałego, ale faktów nie zmienisz.

    Polubienie

Co o tym sądzisz?

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s