Kohana framework

Jelikoz jsem trosku skepticky co se tyce "akceptovani kritiky", tak si dovolim maly experient, ktery by mohl zafungovat i bez "psychicke ujmy" puvodniho pisatele. Pojdme se spolu podivat na nejaky existujici a siroce pouzivany kod a zkritizujme ho, verim, ze se najde spousta "wtf", ktere pak budete moct aplikovat i na svuj vlastni kod, aniz by se nekdo citil napadeny. Zacneme treba rovnou kdysi elegantni kohanou, ktera nam pomalu "baculati" do nehezkych tvaru. repository na githubu: https://github.com/kohana/core/tree/3.1%2Fmaster/classes a rovnou pridam par svych pripominek... Pouzitelnost: - naprosto hloupy (a omezeny) mechanizmus rozsirovani (class Request extends Kohana_Request) - interface hell - uz ted je v kohane vic rozhrani nez kodu. navic uplne zbytecne. - vyvojari asi uplne "bodaji" na kompatibilitu a moznost jednoduse prekopirovat cely adresar s fw - oddeleny bootstrap, index a konfigurak to znacne komplikuji, jinak si to nedokazu vysvetlit. - nutnost dedit controllery, modely Obecne: - static state, uplne vsude a ve vsech podobach - neuveritelne! - velmi casta inicializace a volani externich objektu uvnitr konstruktoru. - konfiguraky vubec - proc se zabyvat parserem, includovanim, cachovanim, atd. kdyz vlastne konfiguraky pisou stejne vyvojari a staci jenom includnout soubor, kterej zavola par setteru. navic s plnou silou php a op-code cache diky APC. - celej fw je nove jeste vice "prolezlej" template method anti-patternem (google call super) - vyjimky - cim vic druhu, tim vetsi dzungle.

Není problém sem poslat cizí kód, ale vyber tedy nějakou konkrétní část. Když hodíš odkaz do repozitáře, nikdo neví, o čem vlastně mluvíš - a nikdo z nás nemá dost času si vytisknout a číst celý framework. Díky za odkaz na "Call super antipattern". Ale už první odkaz říká, že řešením je právě template method, kterou s tím spojuješ. Template method jsem použil minulý týden a dosud z ní cítím velké estetické uspokojení. :)

Note that it is the requirement of calling the parent that is the anti-pattern.

A better approach to solve these issues is instead to use the template method pattern

P.S.: Grafičtí designéři se učí kritiku akceptovat od prvních návrhů, vývojáři by taky měli otevřít své hlavy - budou se posouvat dopředu mnohem rychleji než když se za svůj kód budou stydět. A jak píšu v úvodním příspěvku - hodnotíme kód, ne toho, kdo ho napsal.

Ahoj, puvodne jsem chtel vybrat par casti: - https://github.com/kohana/core/blob/3.1%2Fmaster/classes/kohana/request.php - https://github.com/kohana/core/blob/3.1%2Fmaster/classes/kohana/route.php - https://github.com/kohana/core/blob/3.1%2Fmaster/classes/kohana/session.php ale vicemene ty pripominky plati i pro zbytek frameworku. necekam, ze se vsichni pusti do studia celeho frameworku, tohle bylo spis myslene pro vyvojare, kteri uz kohanu pouzivaji. zbytek se muze podivat na tyhle 3 soubory :) template method je jenom jiny nazev pro "call super", je to po singletonu snad nejhorsi GoF pattern - dedeni obecne je samo o sobe pruser, ale template method z toho dela nocni muru (fragile class). jednoduse receno tim zamezis oddelenemu vyvoji obou trid najednou - pokazde kdyz pridas novou metodu do predka, "zaspinis" vsechny deti (i deti deti) a pokazde kdyz pridas metodu do deti, musis se podivat i do vsech predku, jestli nahodou neco neprepises a nezmenis chovani. pokud tvoje trida pouziva template method, tak musis projit celou hiearchii tridy, abys vubec zjistil, jak jedna konkretni trida funguje. napsat "class Article extends ORM" a ziskat tim mapovani na db tabulku articles je sice fajn, ale mas podstatne vic svazane ruce nez kdyz to ORM uzavres do inst. promenne pomoci kompozice. template metod se bohuzel stal synonymem pro framework, coz u zkusenejsich programatoru vyvolava "obraceni oci vsloup" pri jakemkoliv zmineni "mam aplikaci postavenou nad xxx frameworkem" par lidi v Java komunite si to taky uvedomilo a zpopularizovali "POJO" - takove frameworky uz vyvojare nenuti z niceho dedit a vyuzivaji k integraci meta-data (anotace, xml, apod.), coz je sice taky zlo, ale podstatne mensi. ja zastavam nazor, ze znovupouzivani by melo probihat pomoci kompozice a ne pomoci dedeni.

A jak to teda řešíš? Nepoužíváš Kohanu? Nebo máš svoji ohlou dvojkovou verzi? Dost o Kohaně teď přemýšlím, ale příjde mi, že vývoj je až moc hrrr.

Opustil jsem kohanu nekdy u verze 3.1.2, prestalo me bavit prepisovat kod pri kazdem updatu a dedit u kazde tridy. Napsal jsem si vlastni. Momentalne se ale zajimam o smalltalk. Neni to uplne dokonaly jazyk, ale je nejblize mym idealum - tady je par videi, pokud te to zajima: http://www.world.st/video http://www.pharocasts.com/

jeste stale bych se kohany vubec nebal, pouzivam ji a pouzivam ji rad... Presto pomalu studuji dalsi frameworky, naposledy me zaujal YiiFramework, ale jeste nemam prostudovany jeho vnitrnosti tak abych o tom mohl rict vic

Díky za linky, mrknu. Osobně jsem se zajímal o Kohanu a Nette a u každého mi vadil vývoj a dokumentace. Přešel jsem na Rails a jsem spokojený, Ruby je super jazyk. Teď jenom hledám nějaký intuitivní a malý PHP framework pro klienty, kteří odmítají jinou technologii.

RoR trpi uplne stejnymi problemy (User extends ActiveRecord), jinak ruby je super, to ano, ale narozdil od smalltalku jde o klasicky model "napis, uloz, nacti, najdi chybu, oprav zdrojak, znovunacti", smalltalk (ST-80) je v tomhle porad napred (a to uz je pres 30let stary) - napises tridu, vytvoris instanci, neco se pokazi a rovnou to upravis, nejlepe rovnou z debuggeru, zadne znovunacitani, vse je porad v pameti, vse se da zmenit. a hlavne - ve svete smalltalku mame gemstone/s, coz neni nic jineho, nez upraveny smalltalk, ktery misto do pameti uklada objekty na disk (transakcne), takze uplne odpada potreba relacnich databazi a mapovani na objekty, zjednodusene receno programujeme primo v databazi. (resp. neni tam nic jako databaze, jenom normalni kolekce)