Python: DBC na třicet řádek

5.2.2008 22:22 | Přečteno: 1246× | Ani zbla

Design By Contract (DBC) je programátorské paradigma. Jde o to, že části programu deklarují a mezi sebou dodržují jakési "kontrakty". Nejlépa na příkladu: funkce pro výpočet faktoriálu deklaruje, že jako argument nechce záporné číslo a zaručuje, že vrátí přirozené číslo.

V praxi to znamená, že se třeba k funkcím připisují PRE a POST handlery, které specifukují vstupní podmínky (za jakých podmínek je funkce ochotná pracovat) a výstupní podmínky, tj. co funkce zaručuje po svém návratu. Další možností jsou invarianty, tedy nějaké globálně platné podmínky, například do třídy reprezentující trojúhelník vrazíte středoškolskou poučku, že a + b > c, kde a,b,c jsou délky stran trojúhelníku.

Je to tedy hromada kontrol (assercí); a pohledu aspektově orientovaného programování (AOP) se jedná o aspekt.

Na paradigmatu DBC staví jazyk Eiffel, což je imperativní, staticky typovaný jazyk a to dokonce tak, že DBC je TradeMark nějaké firmy kolem. Eiffel je docela dobrý jazyk, ale nikdy se moc nerozšířil. Různé DBC toolkity jsou ale k dispozici pro všelijáké jazyky.

No a teď proč celý zápisek. Je známo, že v dynamických jazycích je možné řadu složitých "vychytávek" implementovat jednoduše. Třeba jednoduchá proxy třída (RPyC) forwardující volání po síti dokáže nahradit CORBU (milióny řádky kódů, které stejně nefungují) .

No dobře, přeháním, ale třeba to DBC nebo AOP lze v takovém Pythonu nebo Ruby vytvořit snadno. Typicky pár modulů, několik set až tisíc řádek.

Stáhl jsem si PyDBC a jeho jednoduchostí jsem byl skoro šokován. Jedná se o 130 řádek, po odstranění GPL licence v hlavičce a mírné deoptimalizace má funkční jádro 30 řádek, o tu eleganci jsem vás, milí linuxáci, nemohl připravit. Zde je modul mydbc.py

def make_wrapped_call(fun, pre = None, post = None):
	"decorator that calls PRE and POST functions"
	def wrapped(*args, **kw):
		if pre: pre(*args, **kw)
		ret = fun(*args, **kw)
		if post: post(args[0], ret)
		return ret
	return wrapped
    
class DBC(type):
	'Metaclass providing Contract behavior. See module docs for usage.'

	def __init__(cls, clsname, bases, dict):
		super(DBC, cls).__init__(clsname, bases, dict)

		for name in dict.keys():
			feature = dict[name]
			if not callable(feature): continue

			try:
				pre = dict['%s__pre' % name]
			except KeyError:
				pre = None

			try:
				post = dict['%s__post' % name]
			except KeyError:
				post = None

			setattr(cls, name, make_wrapped_call(feature, pre, post))

Jedná se o jeden dekorátor, který volá pre a post handlery a pak magickou třídu DBC. Co dělá magická třída bude jasnější po uvedení příkladu použití:

import mydbc 

__metaclass__ = mydbc.DBC
                        
class Foo:
	def __init__(self):
		self.a = 1

	def foo__pre(self, b): 
		assert not isinstance(b, str) 

	def foo(self, b):
		self.a = b

	def foo__post(self, ret): 
		assert self.a < 5

f = Foo()
f.foo(2)       # calls foo__pre, foo, foo__post

Třída Foo deklaruje atribut a a funkci foo, která atribut nastavuje. Funkce foo má definovány handlery foo__pre a foo__post obsahující asserce. Zásadní kouzlo spočívá ve vytvoření globální proměnné __metaclass__, do které strčíme referenci na naši magickou třídu DBC. Přes __metaclass__ se nabouráme do vytváření instancí tříd, takže pak každou metodu každé vytvořené třídy odekorujeme dekorátorem make_wrapped_call.

Hezké, ne? Skoro začínám věřit Lisperům, že přidávat do jazyka paradigmata dle libosti za všechny ty závorky stojí.

       

Komentáře

[zde]

Paradigmata jsou super věc, lidi co neumí programovat vždycky dají na chvíli pokoj. Jo a proč potřebuje _post handler znát args[0]?

[alblaho]

args[0] je self a ten se může hodit

[Jirka P]

Ono je spíš otázka proč by postcondition neměla mít přístup i k těm ostatním argumentům.

Jinak ten příklad není moc povedený. Protože pokud třeba f.Foo(6) spadne na postcondition, tak je asi něco špatně.

[alblaho]

post k původním parametrům přístup mít může, původní autor to ale udělal takhle

Poslední větu nechápu.

[Jirka P]

post k původním parametrům přístup mít může, původní autor to ale udělal takhle

Aha... To se dost divim, čekal bych, že případů, kde je to potřeba, je víc než málo

Poslední větu nechápu

V poslední větě šlo o to, že DBC by mělo fungovat tak, že pokud má metoda splněné předpoklady a korektní implementaci, tak automaticky splní i postcondition. Ale z třídy Foo a metody foo není vidět, proč by to mělo platit (ani to není pravda).

[alblaho]

Napadá mě, že metoda může nějak změnit parametry, takže je asi fér, když POST kontroluje jen výsledek, tak třeba byla idea právě taková.

No, ale foo třeba korektní implementaci nemá, třeba korektní implementace vypadá takto: self.a = max(b, 4).

[Jirka P]

Jo, metody, který sežerou svoje parametry, třeba v Javě, miluju . Ale proti tomu by se dalo bojovat, ne? Třeba že by se pro POST nechala nějaká copy-on-write kopie, to v Pythonu jde, nebo ne (Python neznám)?

Příklad, kdy je potřeba aby POST dostal i parametry, je třeba metoda, která vrací iterátor na prvek ve stromu hledaný podle klíče, kde ta postcondition je právě to, že vrácený iterátor ukazuje na prvek s požadovaným klíčem.

foo: Záludná otázka: Bylo by to s "self.a = max(b, 4)" správně?

Ale každopádně by bylo mnohem didaktičtější, kdyby ten příklad byl správně a ukazoval jak pěkně všechno funguje.

[alblaho]

Samozřejmě tam má být min(b,4), trklo mě to, jak jsem lezl do postele. To jsou ty komentáře po půlnoci

[Jirka P]

To jsem nemyslel - taky jsem si toho v 1 v noci nevšim Spíš mi šlo o to, že by tam měla být nějaká typová kontrola, aby bylo jasné, že nejde zavolat foo(None) anebo třeba i pokud je b float, tak nesmí být NaN atd...

[Daniel Kvasnička ml.]

Hezky, hezky... Ale kdyz to vidim, tak jsem rad za interfacy a silnou typovou kontrolu v Jave Precejen je to trochu prijemnejsi zpusob specifikace kontraktu, i kdyz to samo o sobe nepokryje vse, co DBC. Doufam, ze konkretne princip rozhrani se do Pythonu dostane co nejdrive.

[alblaho]

Silná typová kontrola sice může eliminovat nějakou třídu chyb, ale já jsem z Javy přešel na Python a po typové kontrole se mi nestýská. U spousty věcí typová kontrola naopak překáží, dynamičnost je super.

[Daniel Kvasnička ml.]

Me typova kontrola zatim vzdy spis pomohla, ve smyslu vetsiho prehledu nad tim, co se kde a jak pri behu programu deje. A ten kod navic, co jsem musel kvuli tomu napsat, to mi zily netrha. Druha vec je, ze uz z principu bude u IDE pro silne typovany jazyk mnohem schopnejsi code asist nez u dynamickych jazyku.

Ja se zas v oblasti webapps posunul k Jave, aniz bych na Python nezanevrel. Ale to uz ani tak neni o typovatosti. Java ma jednak mnohem vetsi ekosystem knihoven na vsemozne veci, J2EE jako standard mi principielne velice vyohvuje (servlety, filtry, taglibs) a vyhovuje mi, ze existuje obecny konsenzus na dodrzovani techhle veci a ze jsou pak implementace v servlet kontejnerech kompatibilni -- coz je prave vec, ktere by treba bez interfacu bylo prakticky nemozne dosahnout...

[alblaho]

Já prodělal posun od Ady přes Javu k Pythonu.

Já se tu rozhodně nehodlám navážet do Javy, protože nástroj je to jistě mocný. Ale třeba vývoj webovky v Djangu, to je 1000x příjemnější záležitost, než co znám z Javy-Tomcatu. Ono na tom Ruby on Rails něco fakt je.

Ale to, že silná typovost implikuje silné IDE pravda jistě je.

Interface je jen abstraktní třída bez implementace, toho lze v Pythonu dosáhnout taky (vícenásobná dědičnost), na tom nic není. Stejně sémantiku těch funkcí definuje nějaká dokumentace. Rozdíl je prostě v tom, že Java to zkontroluje za překladu, Python až za běhu.

[Daniel Kvasnička ml.]

Ale třeba vývoj webovky v Djangu, to je 1000x příjemnější záležitost, než co znám z Javy-Tomcatu. Ono na tom Ruby on Rails něco fakt je.

Tak to bych polemizoval. Minimalne je potreba vedet, o jak rozsahlou aplikaci jde. Kdyz vezmete cely Spring stack a EJB3 s Hibernate a chcete v tom napsat blogisek, tak je asi neco spatne Ja nedam dopustit na Stripes. Naprosto genialni MVC framework, ktery uz pred rokem kdosi oznacil za "the next Rails". Prvni J2EE MVC framework, o kterem se nebojim rici, ze je lightweight. Pak staci jen dobre vybrat knihovnu pro perzistenci (ja osobne celkem preferuju Apache Cayenne, i kdyz je to krava) a nemusi byt vyvoj v J2EE o nic mensi zabava nez Django ci podobne. Kdyz k tomu pripoctete (zatim) nenahraditelne perly jako DWR, tak jedete jako po masle.

Navic, ja ani ten evergreen vsech kritiku J2EE -- totiz XML konfiguraci -- nijak zasadne nezatracuju. Umoznuje totiz zmenu mnoha veci bez rekompilace a redeploye aplikace, XML mi nevadi, edituje se mi dobre a da se zpracovat mnoha nastroji.

Kazdopadne Python je u me taky na vysokych prickach

Interface je jen abstraktní třída bez implementace, toho lze v Pythonu dosáhnout taky (vícenásobná dědičnost), na tom nic není. Stejně sémantiku těch funkcí definuje nějaká dokumentace. Rozdíl je prostě v tom, že Java to zkontroluje za překladu, Python až za běhu.

Jenze ve svete chybujicich lidi je prave dobre, kdyz mate aparat, ktery vam proste naridi, jak to mate napsat -- proto jsou interfacy dobre. Jinak samozrejme chapu, ze se daji do jiste miry emulovat i v Pythonu.

[alblaho]

Kdo chce napsat monstr enterprise aplikaci, tak ať si ji napíše v Javě, já na tom nic špatného nevidím.

Ale správná otázka je, jak velkou aplikaci to Django skousne? Největší aplikace, na které jsem dělal bylo ERP v Javě+Struts+Tomcat s devadesáti tabulkama v databázi. To by Python IMO zvládl líp - výpočtů tam moc nebylo (nevadilo by, že je 10x pomalejší), bottleneck byla jednoznačně databáze.

A k tomu XML, to je moc zajímavé. Zatímco u Javy je XML skvělý doplněk, protože umožňuje změny bez rekompilace, v Pythonu je to v podstatě přebytečná technologie. Jelikož se nic nekompiluje, je mnohem pohodlnější mít konfiguraci přímo v Pythonu XML se pak používá jen na komunikaci s okolním světem.

[Daniel Kvasnička ml.]

Ale správná otázka je, jak velkou aplikaci to Django skousne? Největší aplikace, na které jsem dělal bylo ERP v Javě+Struts+Tomcat s devadesáti tabulkama v databázi. To by Python IMO zvládl líp - výpočtů tam moc nebylo (nevadilo by, že je 10x pomalejší), bottleneck byla jednoznačně databáze.

No jo, tak Struts ...ten konfiguruje pres XML kazdou blbost a i par dalsich nesmyslu obsahuje. Tomu bych se vyhybal jako cert krizi. A jak velkou aplikaci Django skousne? To prave nevim. Neodvazil bych se tvrdit, ze ten jejich vestaveny server zkousne takovou zatez jako servlet kontejner... a nejake zahakovani za Apache, to to mu moc nepomuze. Spis naopak, rekl bych. Celkove deployment Python aplikaci a Djanga neni zadna slast. Prave proto, ze neni nijak standardizovany. Kdyby vzniklo neco jako J2EE pro Python a na tom by pak lide staveli svoje fw a toho by vyuzivali, hned by se nam dychalo lepe...

Pak je taky otazka, jestli myslite Django tak jak je, nebo v nem pulku veci vymenite Pokud chcete pouzivat ten jejich paskvil, ktery tak odvazne nazyvaji templating engine, tak to tedy hodne stesti Princip rozsiritelnosti pomoci taglibs je genialni a v Pythonu se tehle genialite blizi jen Genshi, ktere jsem s Djangem pouzival a pak to stalo za to. ORM bych uz dnes taky vymenil. Pouzil bych SQLAlchemy (kterou stejne ted do Djanga implementuji, i kdyz IMHO naprosto uchylne... pod django ORM), protoze se mi libi, ze jeho domenove tridy jsou maximalni POPO (Plain Old Python Object ) a tabulky se konfiguruji mimo pres tridu Table. Chci mit domenove objekty co nejcistsi.

A k tomu XML, to je moc zajímavé. Zatímco u Javy je XML skvělý doplněk, protože umožňuje změny bez rekompilace, v Pythonu je to v podstatě přebytečná technologie. Jelikož se nic nekompiluje, je mnohem pohodlnější mít konfiguraci přímo v Pythonu XML se pak používá jen na komunikaci s okolním světem.

To jo, jenze mate tu veci jako XPath, XSLT, XQuery, XMLBeans, ktere umoznuji s tim XML delat kejkle skoro bez omezeni -- bez ohledu na technologii. Python konfigurak si rozparsujete v Pythonu a tim to konci. Ale ja fakt, ze se na to musi davat bacha. Stopy XML se na pameti poznaji

[Věroš]

Pak je taky otazka, jestli myslite Django tak jak je, nebo v nem pulku veci vymenite

Místo Django bych zkusil bych Pylons - Ian Bicking a spol. to postavili fakt dobře - dá se vyměnit téměr cokoliv, nasazení na webu je taky jednoduché, prostě samá pozitiva.

Slabší je to s dokumentací, ale chystá se kniha. Vzhledem k tomu, že Pylons obsahují jenom malé množství magie, dá se vystačit s existující dokumentací,.

V současné době ještě hledám, jak udělat některé věci elegantním způsobem(TM), ale Pylons mají budoucnost.

[Daniel Kvasnička ml.]

Na Pylons jsem zbezne koukal, ale uz je to pekna radka mesicu a vim, ze tehdy me moc nezaujaly... Ale asi bych jim mel dat jeste sanci

[Věroš]

Problém je v tom, že to je (jak píše IB) "ravioli code" (srovnej se spaghetti code, resp. lasagne code) - spousta malých nástrojů dobře slepená.

Jen co dodělám asi pět projektů, tak mám v plánu něco o Pylons v češtině napsat - strčím to pak i do blogu na abclinuxu, slibuju.

[Daniel Kvasnička ml.]

Problém je v tom, že to je (jak píše IB) "ravioli code" (srovnej se spaghetti code, resp. lasagne code) - spousta malých nástrojů dobře slepená.

Jo, presne tak mi to pripadlo. Stripky mikronastroju poslepovane do jednoho Ale treba to bude to, co mi nakonec bude vyhovovat...

[Věroš]

Jo. Ale ty nástroje jsou (měly by být) špička v tom co dělají - podobně jako UNIX má asi šestset základních příkazů.

Zatím se mi líbí, že když mi nevyhovuje Routes (ó to je ale rouhání, co?), tak ho prostě vyměním za něco jiného. Jo a SQLAlchemy má ještě týden hájení, pak půjde vyměnit taky. (klidně mne upalte ).

[Daniel Kvasnička ml.]

Jo a SQLAlchemy má ještě týden hájení, pak půjde vyměnit taky. (klidně mne upalte ).

Nebude nutne Priznavam se bez muceni, ze me znalosti o SQLAlchemy jsou na rozdil od SQLObjectu a Django ORM zatim jen teoreticke. Ale z toho, co jsem studoval, jsem mel pozitivni pocity oproti druhym dvema jmenovanym (tedy relativne...ne, ze by SQLObject a Django ORM byly nejake prisernosti).

Takze je mozne, ze jste narazil na neco oskliveho, o cem nevim.

[Věroš]

Největší problém s SQLAlchemy je zatím čitelnost a pochopitenost kódu. Tam vyhrával Elixir (deklarativní nádstavba nad SQLAlchemy), ale zase v době, když jsem ho zkoumal, neměl moc dobře vyřešený přístup z více threadů.

Pro velké projekty bych taky možnost jednoduché kombinace s memcached, ale třeba na to časem přijdu - zatím to vypadá, že SQLAlchemy obalím nějakým vypečeným wrapperem.

[alblaho]

Evidentně do toho vidíte víc, než já. Já Djanguju malou aplikaci a jsem s tím spokojen. Vy chcete větší flexibilitu (vyměnit ORM nebo templating), pak by asi bylo lepší Pylons, které tu zmínil kolega.

Jo a Struts je zastaralý humus, je mi jasné že v Javě je milion mnohem lepších frameworků.

XPath a pod. jsou mocné nástroje, ale na prostou konfiguraci je to trochu overkill.

[Ladicek]

Princip rozsiritelnosti pomoci taglibs je genialni

Jasně, až na to, že JSP je (a to i bez použití skriptletů) víc programový kód než HTML šablona. Ne že by na tom běžné šablonovací enginy (Velocity, FreeMarker) byly líp, ale aspoň je v nich jasně vidět co je co, a průměrný webař se tomu za chvilku přizpůsobí. Použití JSPček se tak redukuje na situace, kdy není v týmu žádný HTML otrok, což jsou kupodivu obvykle situace, kde je lepší použít nějaký komponentový framework. (Obráceně to ale neplatí, např. ve Wicketu jsou HTML šablony tak hezky vymyšlené, že s nimi průměrný webař může začít pracovat prakticky ihned.)

[Daniel Kvasnička ml.]

Jasně, až na to, že JSP je (a to i bez použití skriptletů) víc programový kód než HTML šablona. Ne že by na tom běžné šablonovací enginy (Velocity, FreeMarker) byly líp, ale aspoň je v nich jasně vidět co je co, a průměrný webař se tomu za chvilku přizpůsobí.

A proc by se neprizpusobil JSP? Kdyz neberu v uvahu taglibs psane v Jave, tak se nic krome JSTL a EL ucit nemusi. JSTL je XML (clovek, ktery ma alespon trosku obecnejsi predstavu o XHTML a o tom, ze je to vlastne XML, se nema krome tagu a jejich atributu co ucit) a EL uz primitivnejsi syntax mit ani nemuze... Takovou syntaxi se clovek nauci mnohem rychleji nez nejake to "kolo", co nekdo vymysli.

Mluvim samozrejme o XML syntaxi pro JSP. Pokud vim, da se s ni produkovat i cisty text, takze ten sileny paskvil typu <INPUT TYPE=TEXT NAME=username SIZE=20 VALUE="<%= user.getUsername() %>"> uz snad neni nutne pouzivat...

[Ladicek]

A proc by se neprizpusobil JSP? Kdyz neberu v uvahu taglibs psane v Jave

Což je přesně to, nad čím jste se výše tak rozplýval.

Mimochodem i z mého pohledu programátora jsou tagliby celkem zoufalost: když chcete něco komplikovanějšího, musíte taglibu naimplementovat v Javě, což je jednak dost netriviální a jednak generujete HTML z řetězcových konstant, což je opravdu velmi pohodlné. A když použijete tag file, tak zase neuděláte nic zajímavého, protože v tag fajlu nemůžete použít skriptlet (jediná chvíle, kdy jsem fakt zatoužil nějaký napsat ). Fakt bomba.

(XML deskriptor tagliby už je jenom třešnička na dortu. Ostatně, zajímalo by mne, jestli opravdu pánové od J(2)EE specifikací opravdu nikdy neslyšeli o atributech elementů, nebo měli nějaký vysokosítěný důvod je naprosto vyignorovat.)

Dál tu máme tagliby pro generování formulářových políček ve stránce – to je trochu úchylné a vyloženě programátorskocentrické, přitom je poskytuje snad každý MVC framework. A každý má samozřejmě vlastní. Když je framework trochu rozumnější, poskytne i makra pro Velocity a Freemarker (Spring Web MVC), když ne, spoléhá na podporu Freemarkeru pro JSP tagliby (vy víte kdo).

Narozdíl od takového Wicketu, kde si webař může psát s klidem svoje inputy, jak je zvyklý. Tomu říkám separation of concerns.

Mimochodem, fakt vám přijde příjemnější <c:if test="${!loggedIn}">Přihlašte se!</c:if> než #if(!$loggedIn)Přihlašte se!#end? Mně ani náhodou.

[Daniel Kvasnička ml.]

A proc by se neprizpusobil JSP? Kdyz neberu v uvahu taglibs psane v Jave

Což je přesně to, nad čím jste se výše tak rozplýval.

Nepsal jsem konkretne o psani taglibs v Jave a mel jsem na mysli spise tu druhou moznost. V Jave pisu spis funkce pro EL.

Mimochodem i z mého pohledu programátora jsou tagliby celkem zoufalost: když chcete něco komplikovanějšího, musíte taglibu naimplementovat v Javě, což je jednak dost netriviální a jednak generujete HTML z řetězcových konstant, což je opravdu velmi pohodlné.

To je fakt, to nijak prijemne neni.

A když použijete tag file, tak zase neuděláte nic zajímavého, protože v tag fajlu nemůžete použít skriptlet (jediná chvíle, kdy jsem fakt zatoužil nějaký napsat ). Fakt bomba.

Zbytecne malujete certa na zed. Minimalne tim dosahnete "komponentovatosti" a moznosti nektere veci znovu pouzit.

Dál tu máme tagliby pro generování formulářových políček ve stránce – to je trochu úchylné a vyloženě programátorskocentrické, přitom je poskytuje snad každý MVC framework. A každý má samozřejmě vlastní. Když je framework trochu rozumnější, poskytne i makra pro Velocity a Freemarker (Spring Web MVC), když ne, spoléhá na podporu Freemarkeru pro JSP tagliby (vy víte kdo).

Vy delate, jako kdyby tam byly jen tak. Nechat si generovat adresy pro atribut action muze byt docela zasadni vec, kdyz se v pokrocilem stadiu aplikace rozhodnete menit vazby URL. To vazne spolupracujete s lidmi, kteri maji problem pochopit, ze nebudou psat <form ... />, ale <form ... /> a vymeni par atributu? Ze se panove ze Struts rozhodli uplne nesmyslne vymenit treba atribut class za styleClass, to uz je jejich vec.

Mimochodem, fakt vám přijde příjemnější <c:if test="${!loggedIn}">Přihlašte se!</c:if> než #if(!$loggedIn)Přihlašte se!#end? Mně ani náhodou.

Jo Pro me je to prehlednejsi a nemusim si zvykat na zadnou novou syntaxi.

[Daniel Kvasnička ml.]

v predposlednim odstavci ma byt <s:form ... />

[Ladicek]

Já jsem zvyklý na to, že zrovna atribut action bývá prázdný, protože kontrolér renderující formulář se o request později postará i o jeho zpracování. Jinak mi vážně přijde, že přínos speciálních tagů pro renderování formulářů ani zdaleka neodpovídá tomu, že nemůžu použít plain old HTML.

[Daniel Kvasnička ml.]

(Obráceně to ale neplatí, např. ve Wicketu jsou HTML šablony tak hezky vymyšlené, že s nimi průměrný webař může začít pracovat prakticky ihned.)

Wicket... no, pouzivali jsme to v praci docela dlouho a jeste asi budeme, ale muj skromny nazor je, ze je to z filosofickeho hlediska pekne, ale neproduktivni. I pro relativne jednoduchou funkcionalitu jsou potreba tuny kodu. Ty jejich ultrastrucne sablony mi za to nestoji... A jak se zacnou vynorovat chyby se serializaci a jine, pramenici z toho, ze je to tezce stavova zalezitost.... Nevim, mozna to beru ze spatneho konce, ale pokud chce clovek mit domenove objekty neimplementujici Serializable, tak je to s Wicketem na kocku... samy lazy loading, detachable modely...

Uz i kolem Swingu se vynoruji nastroje na deklarativni psani UI, tak nevim, proc bych na webu mel jit v protismeru.

[Ladicek]

I pro relativne jednoduchou funkcionalitu jsou potreba tuny kodu.

Což s běžnými MCV frameworky jistě neplatí, že. Mám opačný dojem. (Teda se Stripes jsem nepracoval, porovnávám konkrétně se Strutsy a Spring MVC)

Ty jejich ultrastrucne sablony mi za to nestoji...

To jsou i frameworky s mnohem stručnějšíma šablonama , takové RFS, to je teprv maso Výhody se projeví teprve ve chvíli, kdy máte samostatného HTML kodéra.

A jak se zacnou vynorovat chyby se serializaci a jine, pramenici z toho, ze je to tezce stavova zalezitost.... Nevim, mozna to beru ze spatneho konce, ale pokud chce clovek mit domenove objekty neimplementujici Serializable, tak je to s Wicketem na kocku... samy lazy loading, detachable modely...

Že je to těžce stavová záležitost je pro dané účely použití spíš výhoda, přijde mi. A stav by mělo tvořit co nejméně informací, rozhodně ne serializované doménové objekty. Lazy loading považuju za nutnost (zvlášť když třeba budu mít doménové objekty připojené k Hibernatí session), i když tady by mohli pánové od Wicketu trochu zapracovat, protože kód začně být poněkud roztahaný. (Na druhou stranu nemám moc představu, jak konkrétně by se to dalo zjednodušit, ale frameworky obvykle píšou ti chytřejší z nás, tak třeba něco vymyslí )

Uz i kolem Swingu se vynoruji nastroje na deklarativni psani UI, tak nevim, proc bych na webu mel jit v protismeru.

Deklarativní psaní UI… hmm… HTML? JSP je napůl programový kód, to radši upřednostním Wicket, kde mám tu programovou část jasně oddělenou.

[Daniel Kvasnička ml.]

Což s běžnými MCV frameworky jistě neplatí, že. Mám opačný dojem. (Teda se Stripes jsem nepracoval, porovnávám konkrétně se Strutsy a Spring MVC)

To, ze neznate Stripes, vas asi omlouva. Jinak bych si musel myslet, ze jste ve Wicketu nenapsal nic trochu vetsiho... Rozdil mezi Stripes a Wicketem ci treba konkretne Spring MVC je velky (SimpleFormController ve Spring MVC je opravdu k zasmani, kdyz clovek zna Stripes). Podivejte se na JTrac, na to co umi a pak na zdrojaky. Krome toho, ze nejsou pradne zdokumentovane a prasacky psane, je jich groteskne velke mnozstvi na to, kolik toho ta aplikace umi....

Že je to těžce stavová záležitost je pro dané účely použití spíš výhoda, přijde mi. A stav by mělo tvořit co nejméně informací, rozhodně ne serializované doménové objekty. Lazy loading považuju za nutnost (zvlášť když třeba budu mít doménové objekty připojené k Hibernatí session), i když tady by mohli pánové od Wicketu trochu zapracovat, protože kód začně být poněkud roztahaný. (Na druhou stranu nemám moc představu, jak konkrétně by se to dalo zjednodušit, ale frameworky obvykle píšou ti chytřejší z nás, tak třeba něco vymyslí )

Ja jsem si na nemoznost serializace DO nestezoval, uvadel jsem to jako prosty fakt Souhlasim s tim. Ale co mi ta stavovost a vse co z ni prameni dava? A co mi jako cloveku, ktery nema problem s JSP, dava princip Wicketu? Ja jsem mel proste z Wicketu pocit, ze stavi vsechno uplne na hlavu, aby dosahl neceho, co lze jinak dosahnout naprosto trivialnim zpusobem. Ocenoval jsem na nem ale jednu vec. Totiz ze kdyz se logika komponent odehrava kompletne na serveru, je mozne je taky na tom serveru propojit pres nejaky Observer -- to se mi moc libilo.

[Ladicek]

SimpleFormController ve Spring MVC je opravdu k zasmani, kdyz clovek zna Stripes

Nedělá mi problém tomu věřit, vlastně doufám, že to tak je, protože je to pro mě motivace se na Stripes podívat hlouběji (třeba najdu konečně pořádný MVC framework, takové jsou taky potřeba). Jestli mi Stripes bez obstrukcí (a thread-safe) dá aktuální HttpServletRequest a HttpServletResponse, tak jsem v klidu

Ostatně říká se, a tomu taky klidně věřím, že nad Spring MVC je obvykle potřeba napsat si vlastní mini-frameworčík zvící cca 20 tříd (který obvykle obsahuje podporu pro více formulářů na jedné stránce ), pak až je to použitelná záležitost.

A co mi jako cloveku, ktery nema problem s JSP, dava princip Wicketu?

Asi nic moc (když pominu tu stavovost, která je v jistém směru klíčová, a v jistém směru příšerná, protože jde proti základnímu principu webu). Já mluvím z pozice javisty, který má dva metry od sebe specialistu na HTML.

[Daniel Kvasnička ml.]

SimpleFormController ve Spring MVC je opravdu k zasmani, kdyz clovek zna Stripes

Nedělá mi problém tomu věřit, vlastně doufám, že to tak je, protože je to pro mě motivace se na Stripes podívat hlouběji (třeba najdu konečně pořádný MVC framework, takové jsou taky potřeba). Jestli mi Stripes bez obstrukcí (a thread-safe) dá aktuální HttpServletRequest a HttpServletResponse, tak jsem v klidu

V jakekoliv ActionBeane (= controller) staci this.context.getRequest() a this.context.getResponse() a thread safe to AFAIK je. Context je ActionBeanContext obalujici klasicke J2EE zalezitosti + Stripes veci.

[finc]

1000x krat prijemnejsi? Neblaznete. Zalezi na pozadavcich. Pokud se bude jednat o knihu navstev, tak souhlas, pokud ale pujde o enterprise aplikaci s distribuovanymi transakcemi, dobrou skalovatelnosti, atd. tak si Java s Djangem vytre pozadi :)

Interface se neda zamenovat za abstraktni tridu. Pokud budu resit jen signaturu, tak v interface nevytvorite protected ci private metody. Vicenasobna dedicnost je zlo, ktereho se nastesti tvuri jazyka Java vyvarovali. Pokud budu dodrzovat zasady pro psani objektoveho kodu, tak se k vicenasobne dedicnosti nikdy nemohu dostat.

[LesTR]

Pokud budu resit jen signaturu, tak v interface nevytvorite protected ci private metody.

A proc bych to taky delal? Interface popisuje rozhrani tridy, tzn. public metody. Nic dalsiho tam nema co delat a nema co tride kecat do toho, jak si danou vec uvnitr implementuje.

[Ladicek]

Jak dobře škálují distribuované transakce?

[Věroš]

Dobře navržená aplikace v Pythonu bude škálovat podobně jako v Javě. Ale ještě jsem v Pythonu nenašel webový framework, který by se k "umožnit dobře navrhovat aplikace" limitně blížil. Posledním kandidátem je Pylons.

[Daniel Kvasnička ml.]

Ono je to tim, ze ty frameworky ve svych dokmentacich casto lidi nevedou k dobremu navrhu aplikace. Typickym neduhem je zplosteni M slozky z MVC do jedne tridy, resp. vrstvy. Maji tridu jako Model a pouzivaji ji zaroven jako DAO, servisni tridu i domenovy objekt ..treba CakePHP se v tehle uchylnosti vyziva a i Django to ve sve ofic. dokumentaci k modelum ukazuje. Napr. tady: http://www.djangoproject.com/documentation/models/custom_methods/ -- ta sekce Sample API usage uplne bije do oci, tedy alespon me. Servisni metody s SQL dotazy uvnitr domenoveho objektu.......

To ale samozrejme neznamena, ze by se to jinak navrhnout nedalo... ve vetsine frameworku muzete pouzit napr. jejich ORM pro DAO vrstvu, pak si nad ni napsat servisni vrstvu a tu pouzivat z kontrolleru.

[Věroš]

Brrr - u toho odkazu by mělo být varování "jen pro silné nátury", toho jsem si při čtení Djanga ani nevšiml.

Předpokládám, že to je důsledek toho, že vynalézají kolo (aka vlastní DAO) a nepoužijou hotové nástroje - takový SQLObject je tady dlouho.

[Daniel Kvasnička ml.]

No vsak jak pisu vyse, panove uz se rozhodli, ze pouziji SQLAlchemy (alespon jsem na to tema cetl v mailing listu zpravu jednoho z autoru). Akorat se rozhodli, ze zachovaji to sve ORM API a SQLAlchemy nacpou pod to... Nejak mi to hlava nebere. Jestli si jen nejsou schopni priznat, ze neni potreba vymyslet kolo a je jim lito se zbavit neceho, co tak dlouho vyvijeli...

[rADOn]

Vicenasobna dedicnost je zlo, ktereho se nastesti tvuri jazyka Java vyvarovali.

Poroucet programatorum jake konstrukce smi a nesmi pouzivat je mnohem vetsi zlo ktereho se nastesti tvurci dobre navrzenych jazyku vyvarovali.

[Ladicek]

jsem rad za interfacy a silnou typovou kontrolu v Jave Precejen je to trochu prijemnejsi zpusob specifikace kontraktu, i kdyz to samo o sobe nepokryje vse, co DBC.

Will Ye Go Lassie Go

[ajikdpoe]

Prave som dopozeral Neon Genesis Evangelion - The end of evangelion, a myslel som si ze dnes uz na vacsiu sprostost nenarazim. Gratulujem, podarilo sa.

[Messa]

O tomhle jsem četl v knížce od Kenta Becka, ale moc jsem to nepochopil Jaký je rozdíl mezi tím v blogu a tímhle?

class Foo:
	def __init__(self):
		self.a = 1

	def foo(self, b):
		assert not isinstance(b, str) 

		self.a = b

		assert self.a < 5

[Ladicek]

Žádný. Teda kromě toho, že opravdové kontrakty mohou být deklarativní a eventuelně i znovupoužitelné Vlastně kontrakt (jak ho chápu já) je k dokonalosti dovedená aserce, kterou by měla obsahovat (a pohříchu často neobsahuje) každá metoda, která je součástí veřejného rozhraní třídy. A ty další klidně taky

[Messa]

Aha, takže je to něco, o co se může opřít spíš uživatel třídy (programátor pracující se třídou) než samotný autor třídy. A že by mohly být děditelné, to je taky pravda. To už by ve velkých projektech mohlo být užitečné. Díky za vysvětlení To bude tím, že jako příklad se použije vždycky něco triviálního...

[alblaho]

A taky kontrakty lze po odladění vypnout (jako zoufalou optimalizaci), v kódu zůstanou nevyužité PRE a POST handlery, ale nebude to mít žádnou režii. Tvůj kód je sice ekvivalentní, ale ty asserty nejdou jednoduše odstranit (leda prolézáním celého kódu a zakomentováváním).

[Ladicek]

V Pythonu nejdou vypnout aserce?

[alblaho]

Asserce zrovna vypnout jdou, explicitním parametrem při startu interpretu. Ale myslel jsem to tak, že ty kontrakty můžou obsahovat nějakou složitější logiku, která už by se zakomentovávat musela.