Weblabor

Siteépítés három perc alatt, avagy „minden fent van a neten”.

$ pip install Pinax
$ pinax-admin setup_project -b social feszbuk
$ python manage.py syncdb
$ python manage.py runserver

A fenti utasítássorozat eredményeképpen a localhost:8000 alatt kapunk egy webalkalmazást, ami dióhéjban tartalmaz: egy egyszerű Twitter-klónt, fotógalériát, wikit, projektkezelőt, blogmotort, könyvjelzőtárat stb. A Pinax magáról azt hirdeti, hogy rapid webalkalmazás-fejlesztési platform. Valójában ennél több. Ezekről és arról, hogy végül miért nem választottam, az alábbiakban.

Egy webalkalmazás stackben a funkcionalitás túlnyomó része nem projekt-specifikus. (James Tauber előadásában 10%-ra becsülte a „local appok” számát.) Az alkalmazás-fejlesztő keretrendszer környezetet nyújt, irányelveket szögez le, alkalmazás szintű komponenseket nem biztosít, de legalábbis nem feladata. A keretrendszer szerepe, hogy kezelje a munkamenetet, nyújtson adatelérési felületet, tartalmazzon egy ORM-réteget és így tovább. A webalkalmazásba felvitt tartalmak címkézését majd megoldom alkalmazás szinten. És megoldja mindenki. Ez egy olyan összetevő, ami valójában nem alkalmazás-specifikus. Ésszerű megfontolás lehet tehát az, hogy kialakítsunk egy olyan réteget a keretrendszer fölé, amely leveszi a fejlesztő válláról a sablon-funkció kivitelezésének terhét (ne kelljen még egy feed-készítőt írnom), így a projekt egyedi képességeinek kidolgozására tud koncentrálni. Ez teljes mértékben összecseng a Django újrafelhasználható alkalmazásainak (reusable apps) koncepciójával. Visszaugorhatunk régebbre is, és előbányászhatjuk a UNIX „Write programs that do One thing and do it well” filozófiáját.

Django-alapú webalkalmazás felépítése újrafelhasználó komponensekkel

Django alapú fejlesztés során Django a keretrendszer. A webalkalmazás funkcionalitását erre épülő alkalmazás-együttes biztosítja. A cél az, hogy ezek az alkalmazások a lehető leglazábban legyenek szervezve (loosely coupled), hogy későbbi projektekhez is felhasználhatók legyenek. Egy reusable app tehát célszerűen egy konkrét funkcionalitásért felelős (pl. user profil biztosítása). Az ily módon kialakított library-nk lehetővé teszi azt, hogy az említett sablon-funkciók lefedését megoldjuk néhány újrafelhasználható komponens behívásával. Nem mellesleg az appok kiváló tervezési minták a feladat komplexitásának csökkentésére is. Míg az MVC minta horizontálisan különíti el a rétegeket, az újra felhasználható komponensek vertikálisan tagolják a webalkalmazást. További kényelme ennek az elgondolásnak, hogy az appok a Python csomagkezelő rendszerével is összeköthetők, így valóban függetlenné tehetők az akutális munkaprojekttől, és telepítésük, kezelésük is hihetetlen egyszerűvé válik. Fontos megjegyezni ugyanakkor, hogy a Django appok nem pluginok, nem a Django tudását bővítik. A Django fejlesztői-keretrendszer, ezen alkalmazások alatt helyezkedik el a stackben. A Django nem lóg bele az alkalmazás rétegbe.

Egy rugalmasabb minta Django-alapú webalkalmazás felépítésére

Itt jön képbe a Pinax, amely nyílt forrású, Django alapú alkalmazás-fejlesztési platform. Nagy vonalakban: a Pinax előre válogatott alkalmazás-szetteket kínál. Az okoskodásomat indító példában a social gyári projektet választottam ki, ennek eredményeképpen kaptam egy Djangot és vele több tucat, a Pinax-fejlesztők szerint közösségi kategóriába sorolt újrafelhasználható komponenst. Noha már sok esetben az így összerakott bundle-ök is hasznosak, a Pinax ennél többet nyújt. Egyfelől szervesen épít a Python-fejlesztők körében méltán népszerű virtualenvre, sőt a virtualenvwrapperre. (A virtualenv izolált fejlesztői környezetet biztosít az alkalmazás számára, lásd Hardi János Kényelmes Python fejlesztői környezet kialakítása c. előadását.) A feszbuk projekt megnyitásakor a tárgymappában létrejön egy virtuális környezet és az alkalmazáskódot tartalmazó mappa. Rutinus Python-fejlesztők számára lehetőség van a virtualenv kezelést megtagadni tőle, így a már kialakított környezetben fogható munkára. A projekt mappában (értsd: Django-projekt) előre kidolgozott settings modult, deploy-t támogató fájlokat és HTML template-eket kapunk. A Pinax telepítésekor a pip csomagkezelőre épülve feloldja a projekt forgatókönyve szerinti alkamazás-függőségeket, és ezeket a pipes requirements naplóba rögzíti.

A Pinax azonban csak egy eszköz, amelyet bevezetése előtt érdemes mérlegre tennünk. Minden új eszköz egy újabb függőség. A Pinax szervesen épít a Djangóra, így nem árt utánanéznünk, hogy a keretrendszer mely verziói támogatottak. Példának okáért Djangóból a Pinax honlapján foglaltak szerint az 1.0-s települ a 0.7-es stabil Pinax verzióval, de az 1.1-es Django is támogatott. Az 1.2-es várhatóan működik, de nem garantált. Ehhez képest a pip install Pinax a 0.9-est tölti le az 1.2-es béta Djangóval. A Pinaxszal érkező virtualenv integráció újoncok számára értékes, cserébe a már virtuális munkakörnyezettel dolgozóknak egy plusz kapcsolót jelent majd a Pinax rendre utasítása. A Pinax is követi a reusable appok filozófiáját, így valójában valamennyi benne megismert komponens telepíthető tetszőleges Django instanciához. Kényelmes a Pinax projekt kezelése és pipes kötései. Ezek erős érvek lehetnek mellette, mindazonáltal a pipet a deploy szkriptből célszerű vezérelnünk, a Django-projekteket pedig James Bennett tanácsa szerint célszerű előbb-utóbb elhagynunk. A Pinax leginkább egy kiváló proof-of-concept arra, hogy Djangóval a javasolt módszertanok megfogadásával milyen gördülékenyen és gyors ütemben lehet fejleszteni.