Weblabor

Május végén jelent meg a Django 1.2-es kiadása. Az alábbiakban szemrevételezem az 1.2 jellegzetésségeit a teljességre törekvés nélkül. Még a kiadás fejlesztése idején a keretrendszer újdonságainak külön webhelyet nyitottak, ahol a stabil verzió megjelentééig húsz cikk keretében értekeztek a közelgő szolgáltatásokról a téma szakemberei. Forrásanyagul Jacob Kaplan-Moss negyven perces videobemutatója és ahhoz kapcsolódó fóliái szolgáltak még.

A Django API stabilitási elvének köszönhetően a legfontosabb tény, hogy az 1.1-es alkalmazások futnak az 1.2-es környezetben is. A legrégebbi támogatott interpreter viszont immáron a 2.4-es Python.

Csekély változás, viszont mindenféleképpen hasznos, hogy a django.contrib.auth csomagja (tulajdonképpen a Django felhahasználói és authentikációs rétege) immáron elfogadja a @ és . karaktereket is a User modell nevében. Ez lehetővé teszi, hogy e-mail címet használjunk felhasználónévként.

Ennél egy fokkal érdekesebb az m2m_changed szignál bevezetése. Az alkalmazások figyelhetik a sínre küldött jeleket, és reagálhatnak rá. Ezidáig a modellek közötti több-több kapcsolatért felelős mező változását igen körülményesen lehetett csak elkapni.

Django forráskód-részlet (fotó: Török Gábor)

Nagyobb horderejű változás a Google of Summer Code keretében kidolgozott párhuzamos adatbázis-kapcsolat támogatása. Ez azt jelenti, hogy az alkalmazást konfigurálhatjuk úgy, hogy egyidejűleg több, akár különböző típusú adatbázis motoron dolgozzék. Használatával kialakítható keretrendszer szinten egyfajta szegény ember replikációja. A használandó adatbázis per lekérdezés a using() metódussal adható át. Ennél rugalmasabb kialakítást tesznek lehetővé az adatbázis routerek.

Amíg csak teheti, a Django lusta lekérdezéseket használ, ám így is számos esetben túl nagy erőforrást visz el az ORM. Az 1.2-es előtt is megvolt a lehetőség az ORM kikerülésével közvetlenül SQL-t küldeni az adatbázis felé, de ilyenkor a visszakapott érték is nyers adathalmaz volt, amiből szükség szerint nekünk kellett újra előállítanunk a modelleket. Ezt a kényelmetlenséget oldja fel a raw() metódus, amely bemenetén továbbra is pucér SQL állításokat vár, de a visszatérési értékét már a Django model rétegén tolja át.

Ha egy modellhez beviteli felültet kívánunk készíteni, elé tehetünk egy űrlap modellt (ModelForm) és kész is. Ha szabályozni szeretnénk a látogató felől jövő adatokat, erre az űrlapmodell lehetőséget ad. De mi a helyzet abban az esetben, ha a modellbe közvetlenül töltünk vagy tölt más fejlesztő adatot? Azon túl, hogy az adott mező típusa leszűkíti a lehetőségeket, az 1.1-es Django User modelljének nevébe szemrebbenés nélkül pakolhattunk @ karaktereket, holott az csak az 1.2-estől támogatott. Ezt a hiányosságot pótolja a modell validáció bevezetése. A szintén GSoC alatt kimunkált felület az űrlapoknál már megismert mintát követi. Az újrahasználhatóság jegyében mind az adat-, mind az űrlapmodelleknél bevethetők ugyanazon validátorok.

Ezidáig a django.contrib.auth-hoz volt tapasztva egy üzenet-kezelő réteg, amellyel a komponensek az egyes iterakcióról tájékoztathatták a felhasználót egy egységes felületen. Ezt most az auth-ról leválasztották és kiemelték az önálló django.contrib.messages alkalmazásba. Az új keretrendszer az adatbázis alapú session tároló mellett sütikbe is tudja menteni az üzeneteket. Származékos előnyként kevésbé terheli az adatbázist, másfelől nem bejelentkezett, anoním látogatók részére is lehet így üzenetet küldeni. Az API tervezésénél a pythonos logging függvénytárat vették alapul.

Utoljára említeném a gyorstárazott template betöltést. Ezidáig a Django saját template motora mindig beolvasta diszkről, majd lefordította a sablonokat. Az új cached.Loader első beolvasást és compile-t követően már a memóriából szolgálja ki a sablonokat, jelentős teljesítményfokozást elérve ezzel.