Climbus Blog

Jarek Zabiełło w komentarzu wspomniał abym napisał coś o wadach Pylonsów. Oczywiście, jak każdy soft i Pylons ma trochę wad. Jednak aby obraz był jaśniejszy postaram się zrobić małą analizę SWOT frameworku.

Jeżeli ktoś nie wie co to jest analiza SWOT odsyłam do wikipedii: SWOT. W skrócie analiza SWOT dzieli się na: S (Strengths, Mocne strony), W (Weaknesses, Słabe strony), O (Opportunities, Szanse), T (Threats, Zagrożenia).

Opisanie tych punktów daje w miarę pełny obraz badanego przedmiotu.

A więc zacznę od mocnych stron:

Standard WSGI

Moim zdaniem najmocniejszą stroną Pylonsa jest oparcie o pojawiający się w pythonie standard WSGI (od Pythona 2.5 implementacja jest w bibliotece standardowej). Pozwala on na korzystanie z kodu innych projektów. Dowodem może być to, że Pylons pojawił się nagle, wydawać by się mogło z niczego. Nagle powstał framework z dość sporą funkcjonalnością. Co się okazuje Pylons jest składanką wielu projektów, często poprzez warstwę WSGI.

O WSGI napiszę trochę w przyszłości bo jest to ciekawy temat.

Modularność

Jak wspomniałem przed chwilą Pylons jest składanką różnych projektów. Można wymienić kilka najważniejszych części: Paste (główny silnik, tworzący i zarządzający aplikacją WSGI oraz dostarczający sporo Middleware), Routes (biblioteka odpowiedzialna za mapping adresów url), Beaker (sesje i cache), Myghty (początkowo główny silnik szablonów i kontrolerów, teraz ma mniejsze znaczenie), SQLObject, SQLAlchemy (warstwa danych), Buffet (Interface do szablonów).

Sam Pylons składa się ze stosunkowo małej ilości kodu. Całą robotę “odwalają” powyższe projekty. Wydaje się, że każdy komponent można stosunkowo łatwo wymienić. Nie ma ścisłej zależności, czego przykładem może być Myghty, który na początku był wiodącym składnikiem teraz jest wypierany przez inne projekty (np. wkrótce domyślnym systemem szablonów będzie Mako).

Wypróbowana jest wspópraca szeregu systemów szablonów: Myghty, Mako, Cheetah, Genshi, Jinja, Kid, oraz silników baz danych: SqlObject, SqlAlchemy, Plain DB-API, ZODB, Durus itp.

Czerpanie wzorów

Głównym inspiratorem frameworku był Ruby on Rails. Jak wiadomo jest to całkiem udany kawałek kodu zdobywający coraz większą popularność. Dużo bardzo dobrych cech została przejęta z Railsów np. WebHelpers (powstała pythonowa wersja), Routes (również na potrzeby frameworku powstała pythonowa wersja), struktura katalogów aplikacji, komendy generatora kodu (paster controller, paster shell).

Autorzy obserwują też inne projekty i starają się wyciągnąć wnioski. Z CherryPy i TurboGears wzieli bibliotekę do podłanczania systemów szablonów, połączenie z SQLObject. Powstający nowy system szablonów Mako, przy ścisłej współpracy z autorami Pylonsa jest wzorowany silnie na Myghty oraz bierze conajlepsze z Django czy Chetah.

Wszystko musi być Pythonic

Jako framework pythonowy Pylons musi być napisany w idei Pythonowej: jak największa zgodność z wytycznymi PEP’ów, musi być przyjemny dla pythonowców.

Nic na siłę. Jeżeli się czegoś nie da wyrazić w pythonie bez niepotrzebnych haków, nie ma sensu tego wkładać do frameworka. Wszystko oparte o koncepcję “Keep it Simple, Stupid” co pozwala na łatwiejsze utrzymanie kodu.

Autorzy z doświadczeniem

Pylonsa tworzą ludzie z niemałym dorobkiem webowym i pythonowym. Obili się o parę projektów i doszli do wspólnych wniosków. Na pewno się przekonali, że autorskie rozwiązania nie współpracujące z innymi projektami prowadzą donikąd.

Co jeszcze warto podkreślić, autorzy chętnie pomagają w rozwiązywaniu problemów oraz dają się przekonać do dobrze uzasadnionych zmian w projekcie. Można ich zastać na ircu lub grupie dyskusyjnej.

Wszystko w paczkach

Dzięki setuptools i egg możliwe jest utrzymanie zależności od wielu bibliotek. Zazwyczaj wystarczy jedna komenda do zainstalowania Pylonsa i jego zależności. Każda aplikacja również jest paczką egg, więc wystarczy spakować ją, przegrać na serwer i uruchomić instalację. Wszystkie zależności łącznie z samym frameworkiem zostaną zainstalowane.

Kompatybilność

Autorzy Pylonsa starają się zachować kompatybilność wstecz. Każda zmiana w api jest opisywana w release notes, do kodu wstawiane są deprecated warnings, w sytuacji gdy było dużo zmian w wersji 0.9 wstawiony został tryb zgodności do zachowania kompatybilności z projektami napisanymi pod 0.8. Wydaje się, że powyżej wersji 1.0 na kompatybilność zostanie położony jeszcze większy nacisk.

Moim zdaniem są to najważniejsze mocne strony Pylonsa. Wkrótce wyżyję się trochę i opiszę jego słabe strony.

Do przeczytania wkrótce.

Swoją przygodę z programowaniem webowym zaczynałem oczywiście z PHP. Jak każdy wie, jest to najbardziej bałaganiarski język z możliwych:) Pozwala na prawie wszystko. Oczywiście da się w nim coś konkretnego i eleganckiego wyklepać lecz jest do dość trudne i wymaga mocnego pilnowania siebie i swoich współpracowników. A zmiany w aplikacjach napisanych przez kreatywnych “programistów” są niemal samobójstwem.

Los skierował mnie w stronę Pythona. Pierwszym poznanym frameworkiem był CherryPy. Był to koniec CP1 i sam początek CP2. CP jest bardzo ciekawe i co najważniejsze bardzo proste. Bardzo łatwo ogranąć kod i wiadomo co i gdzie się dzieje. Niestety koderom CP trochę brakuje rozwagi i potrafią zmieniać różne rzeczy bez powiadomienia i bez większej zmiany numerka wersji. Tak było np. z obsługą forków. Cały czas była wzmianka o tym w dokumentacji lecz wcieło kod to obsługujący. Pytaliśmy się lidera projektu i się dowiedzieliśmy, że nie będą tego obsługiwać. Duży projekt musieliśmy zamrozić w danej wersji CP. Naszczęscie najważniejsze zmiany mogliśmy sami nanosić. Przy okazji mogliśmy pooglądać miejsca gdzie ktoś zapomniał dopisać kodu.

Następnym frameworkiem był Webware. Stary, poczciwy kawałek kodu napisany dawno temu i już chyba zapomniany (aczkolwiek webware jest ciągle rozwijany). Niestety dokumentacja nie jest najlepsza i ciężko się w niej szuka informacji. Doszedłem jednak do wniosku, że nie jest zbyt nowoczesny i elastyczny. Poszedłem dalej:)

Zastanawiałem się nad Spyce, lecz jest trochę przekombinowany. Próbuje naśladować php’a i udaje się to przynajmniej przy błedach. Potem był Myghty. Podobno dobrze dopracowany i bardzo szybki lecz mało (jak dla mnie) intuicyjny i wzorowany na frameworku Perlowym. TurboGears jet oparty na CP więc odpadł od razu.

Oczywiście obserwowałem Zopa lecz nie mogłem doj do wniosku czy wchodzić w Zopa2 czy w Zopa3. Trójka ma mało gotowych produktów, nie jest tak popularna i ma skromną dokumentację. Na Zopa Dwa szkoda mi było czasu.

Dochodzimy do “współczesności”. Obecnie chyba najwiekszą popularnością cieszy się Django. Podchodziłem do tego frameworku lecz jak musiałem zacząć projekt, w Django zaczęła się mocna przebudowa “magic removal” więc się nie odważyłem kontynuować w tamtym momencie. Ponadto wydaje mi się, że nie jest zbyt elastyczny jak na dziwne wymagania jakie spotykam.

Najciekawszym projektem jest Pylons. Jest to przykład jak z wielu zlepków istniejącego kodu może powstać bardzo ciekawy projekt. Tak naprawdę źródła sa stosunkowo małe. Pylons jest raczej klejem który integruje różne biblioteki: Routes, WebHelpers, Myghty, Baker, Paste i wycinki CP i TG. Sercem webowym jest WSGI. Deweloperzy Pylonsa są ludźmi świadomymi i często słuchają użytkowników. Wiedzą co to jest stabilność API. Oczywiście projekt nie jest pozbawiony wad i jest we wczesnym staduim rozwoju. Poczekamy, zobaczymy do czego dojdzie. Narazie się skupiam na progrmowaniu w Pylonsie. Więc dołączyłem do klanu Pylonautów:)