Django-obujen periminen
Markus Törnqvist
Kun nyt eilen oli kaljalla puhetta n�kymien tekemisest� luokkina, joita
voi periytt�� asioiden kierr�tt�miseen, ja ties mist� modelien moniperimisest�
niin inspiroiduin tekem��n jotain vastaavaa formien kanssa.
Tein ihan vain objectista perityn helperin, joka toteuttaa metodit
clean_url() ja save_site()
Ajatuksena oli, ett� sen voi heitt�� mukaan moniperinn�ll�, ja se jopa
toimii.
Joku cleaned_data on sellainen, ett� accessoin suosiolla selfin kautta,
mutta muu menee argumenteissa.
T�� nyt on v�h�n t�llainen koe, ett� milt� tuntuu kirjoittaa t�llainen
koodi, mutta saa toki fleimata noilla multiple inheritance considered
harmful -linkeill� ja muulla jos silt� tuntuu ;)
Mietin vain, ett� onko listalaisilla tullut usein sit tilanteita vastaan,
joissa on n�pp�r�� k�ytt�� enemm�nkin moniperint��, ilman harmfulnessi�?
Yksi keissi voisi olla, ett� formilla lis�t��n k�ytt�j� ja saitti, mutta
on my�s muualla ominaisuus lis�t� k�ytt�j� tai saitti erikseen, jolloin
tuossa voisi tehd� aika hyv�� pirstaloimista k�ytt�j�- ja
saitti-helper-obuihin, jotka ei v�ltt�m�tt� ole edes peritty forms.Formista.
Kuitenkin on pakko k�ytt�� forms.Formia, jotta saa ne fieldit kohdilleen.
class FofoRegistrationForm(forms.Form, UserFormHelper, SiteFormHelper, PasswordFormHelper):
"""Example of insanely multiple-inherited form
"""
user = ...
password = ...
site = ...
def save(self):
# UserFormHelper
self.save_user(...)
# PasswordFormHelper
self.set_password(...)
# SiteFormHelper
self.save_site(...)
tjsp.
--
mjt
Jukka Välimaa
Moi!
Kun nyt eilen oli kaljalla puhetta näkymien tekemisestä luokkina, joita
voi periyttää asioiden kierrättämiseen, ja ties mistä modelien moniperimisestä
niin inspiroiduin tekemään jotain vastaavaa formien kanssa.
Tein ihan vain objectista perityn helperin, joka toteuttaa metodit
clean_url() ja save_site()
Ajatuksena oli, että sen voi heittää mukaan moniperinnällä, ja se jopa
toimii.
Joku cleaned_data on sellainen, että accessoin suosiolla selfin kautta,
mutta muu menee argumenteissa.
Tää nyt on vähän tällainen koe, että miltä tuntuu kirjoittaa tällainen
koodi, mutta saa toki fleimata noilla multiple inheritance considered
harmful -linkeillä ja muulla jos siltä tuntuu ;)
Mietin vain, että onko listalaisilla tullut usein sit tilanteita vastaan,
joissa on näppärää käyttää enemmänkin moniperintää, ilman harmfulnessiä?
Yksi keissi voisi olla, että formilla lisätään käyttäjä ja saitti, mutta
on myös muualla ominaisuus lisätä käyttäjä tai saitti erikseen, jolloin
tuossa voisi tehdä aika hyvää pirstaloimista käyttäjä- ja
saitti-helper-obuihin, jotka ei välttämättä ole edes peritty forms.Formista.
Kuitenkin on pakko käyttää forms.Formia, jotta saa ne fieldit kohdilleen.
Markus Törnqvist
>Morjes,
>
>esimerkki mik� tulee nyt mieleen on kaksi spesialisoitua formia, joista
>toinen osaa tehd� json:ia javascriptiwidgetti lomakkeen tekoa varten, ja
>toinen osaa j�rjest�� kent�t automaattisesti haluttuun j�rjestykseen. Noita
>ei yleens� tarvitse sekoittaa, mutta sitten kun haluaa j�rjest��
>dynaamisesti jonkun niist� javascripti formeista, niin lykk�� vaan
>j�rjestysformin mukaan moniperinn�ll�.
Unohdinpa kokonaan vastata t�h�n, katsotaan saanko en�� otetta mist��n :D
Oon k�ytt�ny mixinej� joskus dynaamisesti uusien obujen luontiin, eli
runtimessa rakennan noi asiat.
Musta tuntuu, ett� se kalaisa syntaksi
FooClass.__bases__ = FooMixin + FooClass.__bases__ + BarMixin
mit� vaaditaan ei oo yht� tyylik�s kuin yksinkertaisesti moniperiminen.
Tietysti tollasen voi duunata jonkinlaiseen funktioon, jota vain
kutsua, mutta jotenki nyt t�kkii.
Silloin kun tarvitaan vain staattista kamaa, niin onko jotain syyt�
miksi ei vain k�ytt�isi moniperint��?
Taitaa olla makuasia ;P
--
mjt
Jukka Välimaa
On Sun, Jan 24, 2010 at 05:21:24PM +0200, Jukka Välimaa wrote:
>Morjes,
>
>Tuohon on ns. mixin luokka. Tuollaisille on kyllä tullut käyttöä. Yksi
>esimerkki mikä tulee nyt mieleen on kaksi spesialisoitua formia, joista
>toinen osaa tehdä json:ia javascriptiwidgetti lomakkeen tekoa varten, ja
>toinen osaa järjestää kentät automaattisesti haluttuun järjestykseen. Noita
>ei yleensä tarvitse sekoittaa, mutta sitten kun haluaa järjestää
>dynaamisesti jonkun niistä javascripti formeista, niin lykkää vaan
>järjestysformin mukaan moniperinnällä.
Unohdinpa kokonaan vastata tähän, katsotaan saanko enää otetta mistään :D
Oon käyttäny mixinejä joskus dynaamisesti uusien obujen luontiin, eli
runtimessa rakennan noi asiat.
Musta tuntuu, että se kalaisa syntaksi
FooClass.__bases__ = FooMixin + FooClass.__bases__ + BarMixin
mitä vaaditaan ei oo yhtä tyylikäs kuin yksinkertaisesti moniperiminen.
Tietysti tollasen voi duunata jonkinlaiseen funktioon, jota vain
kutsua, mutta jotenki nyt tökkii.
Silloin kun tarvitaan vain staattista kamaa, niin onko jotain syytä
miksi ei vain käyttäisi moniperintää?
Markus Törnqvist
>Kyll�h�n min�kin k�ytin moniperint��. Eik�s mixinin tee se ett� se luokka on
>tarkoitettu mukaan lyk�tt�v�ksi pakettifunktionaalisuudeksi, se lyk�t��nk�
>se mukaan moniperinn�ll� vai tuolla kalaisella syntaksilla on toinen juttu?
M� olen aina mielt�nyt ett� mixin on se menetelm� miten niit� miksataan,
muuten kuin moniperinn�ss� - moniperint�h�n meinaa sit ett� jokainen
luokka, ml. object, on mixin-luokka, jolloin termi kattaa niin kaiken,
ett� se menett�� arvonsa ;)
Tietty sit� vois nimet�, usein nime�� mixin-menetelm�lle "tarkoitetut"
luokat *Mixin tai *MixinClass, ja *Interface tai joskus unkarilainen
I* on n�hty moniperint��n.
T�ss� m� nyt nimesin *Helper koska ne sis�lt�� vain metodeja, ei
varsinaisesti interfacea, jota olisi mielek�st� kutsua muualta, eik�
mixinej� joita k�ytt�isin dynaamisesti.
Ehk� t�� menee sit siihen kategoriaan, ett� projektin alussa tapellaan
konventiot kuntoon ;)
--
mjt
Ari-Pekka Repo
On Jan 28, 2010, at 2:43 PM, Markus Törnqvist wrote:
> On Thu, Jan 28, 2010 at 02:30:28PM +0200, Jukka Välimaa wrote:
>> Kyllähän minäkin käytin moniperintää. Eikös mixinin tee se että se luokka on
>> tarkoitettu mukaan lykättäväksi pakettifunktionaalisuudeksi, se lykätäänkö
>> se mukaan moniperinnällä vai tuolla kalaisella syntaksilla on toinen juttu?
>
> Mä olen aina mieltänyt että mixin on se menetelmä miten niitä miksataan,
> muuten kuin moniperinnässä - moniperintähän meinaa sit että jokainen
> luokka, ml. object, on mixin-luokka, jolloin termi kattaa niin kaiken,
> että se menettää arvonsa ;)
Kyllä mixin luokalla on aika selkeä semanttinen ero ns. normaaliin luokkaan verrattuna. Se on nimenomaan toiminnallisuuden paketoimista abstraktiin luokkaan, jota voidaan käyttää melko vapaasti siellä sun täällä moniperinnän avulla. Mixin käsitteenä ei liity mitenkään siihen, heitetäänkö niitä mukaan dynaamisesti vai ihan staattisesti perimällä, määritelmä on lähinnä käsitteellinen.
-ap