Django a rozšiřování User modelu

30.7.2007 21:16 | Přečteno: 2390× | | poslední úprava: 31.7.2007 09:14

Před časem jsem se rozhodl, že když už je to mezi mnou a vývojem web apps tak vážné, nezůstanem u PHP a praštíme do toho. Začal jsem objevovat Python na webu, prošel jsem několik různých technologií a frameworků (což nutně neznamená, že jsem je zase opustil) a dnes bych rád lehce rozebral jeden problém, na který jsem narazil při práci na jedné větší věci v Djangu.

Django u mě dříve hrálo druhé housle a to díky TurboGears a čistým mod_python handlerům (svůj Cocoon-like framework se doufám brzy dokopu vydat jako opensource), ale pro ten současný projekt jsem se rozhodl, že mu dám šanci. A stálo to za to. Pochopil jsem více jeho odlišnosti, jeho sílu (i když k používání jejich "templating engine" mě nikdo nedonutí -- Genshi od tvůrců Tracu je neskutečně mocný nástroj), ale také jsem narazil na pár otravných problémů. (Mj. pro mě naprosto nepochopitelný záměr vývojářů Djanga nemít žádnou generovanou API dokumentaci...prý jejich klasická dokumentace stačí...hehe. Kůži nám naštěstí zachraňují hned dva aktivisté: http://djangoapi.matee.net/ a http://djangoapi.quamquam.org/trunk/. Je tu mimochodem vidět, že u Djangů doma se na dokumentování kódu často celkem obstojně kálí...)

Rozepsat se chci o problému s odvozováním datových modelů prostou objektovou dědičností, které je alternativou (těžkopádnému a ošklivému) řešení s ForeignKey či OneToOne poli. Kdo by si myslel, že je to přirozené a bez problému to půjde, narazí. Dá se dostat celkem daleko, v podstatě vše kromě reflektování změn v modelu v admin rozhraní lze jednoduše udělat. Stačí vytvořit nový model, příp. odvodit i vlastního managera a udělat formulářové třídy (třeba na košatější registrační formuláře -- tam jsem ale narazil ještě na problém, že SelectFieldu nelze vnutit defaultní hodnotu -- prý to není věc Djanga, bug byl uzavřen -- takže se konalo další subclassování a pak vytvořit vlastní backend, abyste donutili Django se autentizovat oproti vašemu novému modelu. Pokud ale chcete dodatečné informace zobrazovat a editovat v admin rozhraní, narazíte na problém. Přepsání vnořené třídy Admin, která definuje vzhled admin rozhraní, totiž nemá žádný efekt.

Řešením je ještě před odvozením nové třídy pro uživatele tu stávající třídu a podtřídu Admin "nadopovat" položkami, se kterými potřebujete pracovat.

Mějme tedy uživatele, ke kterému potřebujeme registrovat nějaké ty oblíbené položky.

from django.contrib.auth.models import User

class MyUser(User):
	favorites = models.ManyToManyField('AdSpace', blank = True)

	class Meta:
		db_table = 'auth_user' # To abychom donutili MyUser pracovat nad tabulkou, kam si Django ukládá uživatele

Ty většinou jako administrátoři nebudeme potřebovat editovat, je to věc každého uživatele. Řekněme ale, že chceme mít přístup k adrese. Přidání např.

mesto = models.CharField('Město', maxlength = 50, blank = True)

a předefinování proměnné fields ve vnořené třídě Admin nám mesto do admina nedostane. Chyba žádná, ale položka se prostě nezobrazí, jako kdyby neexistovala. Takže před definici MyUser dáme:

User.add_to_class("mesto", models.CharField('Město', maxlength = 50, blank = True))
User._meta.admin.fields += (
        ("Adresa", { 'fields': ('mesto', ) }),
)

a hned máme v Admin rozhraní fieldset s položkou město. Výhodou je to, že položka je přímo v editaci uživatele, žádný další model nepotřebujeme (= méně objektů v paměti a méně dotazů do DB) a do našeho nového modelu si můžeme nasypat metody pracující pouze nad daty našeho modelu a pak je v requestu volat podle libosti (ovšem za předpokladu, že máme vlastní backend, který nám po přihlášení vrátí instanci MyUser a ne User). Nevýhodou je to, že metoda add_to_class bere pouze self a dva argumenty, takže pro přidání 10 polí ji musíme volat 10×. Přidat si samozřejmě můžeme i nová pole, která chceme zahrnout do hledání (čárka za 'mesto' je povinná):

User._meta.admin.search_fields += ('mesto', )

atd... Jinak mi ale Django dělá radost a přes všechny neduhy je to celkem povedený kousek software.

UPDATE: Problém nastává, když se pokusím přes add_to_class přidat ForeignKey na sebe sama. To zacyklí dev server tak, že ho musím sestřelit. Přidání ForeignKey na sebe sama přímo v třídě samozřejmě funguje, ale to neřeší můj problém s adminem. Včera jsem si v jednu chvíli zacyklení všiml až pozdě, obě jádra jely na 100%, 2GB paměti v háji a swap skoro taky... Reset už jsem v Linuxu opravdu dlouho nepoužil

       

Anketa

Komentáře

[xm]

Django je dle mého názoru nejlepší webový framework vůbec (a že už jsem jich hodně vyzkoušel). I ono má své mouchy, ale tak jako tak je to špička, kam se na něj hrabe třeba Ruby On Rails...

[Daniel Kvasnička ml.]

O webovych frameworcich se tezko rika nejlepsi ci nejhorsi pokud nespecifikujete oblast. Urcite s vami souhlasim, ze na vetsinu scenaru je Django spicka, ale jsou pripady, kdy muze byt clovek produktivnejsi napr. s low-level frameworky typu CherryPy.

[Pavel 'lingeek' Szalbot]

Článek by se klidně mohl jmenovat Django a rozšiřování modelu. Problematiku hezky popisuje např. http://www.b-list.org/weblog/2007/02/20/about-model-subclassing.

Sám Django používám něco přes rok. Ve zkratce - spokojenost zatím zůstává velká, většina problému se dala snadno vyřešit, ušetřeného času mraky. Největší radost mi udělal nový modul newforms a překvapila mě neuvěřitelně snadná lokalizace aplikace. Aktuálně řeším optimalizaci SQL dotazů.

Z poslední doby doporučuju Django Master Class.

[Daniel Kvasnička ml.]

Článek by se klidně mohl jmenovat Django a rozšiřování modelu. Problematiku hezky popisuje např. http://www.b-list.org/weblog/2007/02/20/about-model-subclassing.

Moc dobre napsany clanek, dik za link. Celkem se zacinam pripravovat na to, ze se subclassovani v tomto pripade vzdam. Nejde o princip, spise o cas, ktery stravim rewritem. S edit_inline u ForeignKey dosahnu snad prakticky stejneho efektu a ztratim u toho mene mozkovych bunek...

Z poslední doby doporučuju Django Master Class.

Jo, jo, tahle stranka uz mi sedi v del.icio.us Tech dobrych prezentaci je tam vice.