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.