[2009-07-16] beforePrepare() & prepare<View>() deprecated. Co s tím?

Teším sa spolu s Nette :)

Paráda…na šablony se těším víc jak na Ježíška :D

EDIT: Něco ohledně stable a development už tu zaznělo (pardon, dostal jsem se k tomu až teď, tenhle topic je přeci jen novější a stable a development je navrhováno o něco níže v seznamu).

To s tou dokumentací je určitě pravda. Před 3 dny jsem se životním cyklem Presenteru zabýval trochu podrobněji a celkem se mi tam metody prepare<View>() zalíbily. Já jsem dokumentaci pochopil tak, že ve fázi interaction se předpokládá nejčastější výskyt chyb (rozuměj tak, že v této fázi by na výstupu nemělo ještě nic být, takže jakékoliv přesměrování je možné a i žádané, pokud se tedy potřebuji spojit s databázi a něco si vybrat (byť třeba s použítím modelu), měl bych se o to pokusit ještě v této fázi, aby případná chyba způsobila přesměrování na ErrorPresenter. Většinu věcí, co jsem dřív dělal přes render<View> jsem přesunul do prepare<View> (a ten kód se o dost lépe četl, protože jsem přesně věděl, že v render<View> nastavuji jen věci pro šablonu a v prepare<View> mám načítání a přípravu (u presenteru pro RSS feed tam např. mám nastavení ContentTypu na application/xml).

Je zřejmé, že i když databáze selže v rámci foreach cyklu při vykreslení šablony, tak už se přesměrování nedočkáme, toho se vyvarovat nejde, ale když budu vědět, že se k databázi dostanu už během prepare, tak bude času pro selhání (a následné přesměrování) dost a dost.

Asi nebudu mít problém s předěláním toho, co zatím mám, na systém bez prepare<View> a beforePrepare, ale je škoda, že neexistuje víc verzí dokumentace. Už by to chtělo uvažovat o tom, jestli nedělat pro každý tag v svnku novou verzi dokumentace a řídit se pravidlem – udělám-li tag, budu v něm upravovat jen chyby a nebudu nic měnit nebo přídávat. Už jsme ve fázi, že je třeba řešit i zpětnou kompatibilitu (i když to ne každý rád slyší) a tohle bude jedině krok správným směrem. Věřím tomu, že dost nových uživatelů může pár takových „zbrklých“ změn odradit, protože to může být dost matoucí. Přece každý, když přijde k něčemu novému, si potřebuje stáhnout něco, co bude funkčně shodné s dokumentací. Pokud mu bude něco chybět, nahlédne do dokumentace jiné verze a tam to buď najde, nebo nenajde.

Možná ten přístup s tagama není úplně nejlepší, určitě by to šlo řešit i jinak. Třeba k tomu přidat ještě další větve a dělat to třeba tak, jak to řeší např. Debian (mít stable, unstable a testing větev a pro každou takovou větev udržovat dokumentaci). Vyvstane tady potřeba řešit i životní cyklus vývoje – tzn. kdy se z unstable stane testing, kdy z testing stable, atd.

Vím, že to, co jsem napsal výše, jsou jen takový výkřiky, ale už dlouho jsem to chtěl někomu říct a tenhle topic mě k tomu přímo navedl.

Editoval m0t3jl (17. 7. 2009 11:47)

David Grudl napsal(a):

Tzv. „dokumentační projekt“ skutečně zamrzl a budu se muset do dokumentace pustit sám. Každopádně mám v plánu co nejdříve vydat nějaké release candidate 0.9, kde budou všechny zásadní změny promítnuty a budu moci k tomu napsat dokumentaci. Tato verze bude nabízena jako výchozí ke stažení a 0.8 zůstane jen v archívu. Tudíž verzování dokumentace zatím nebude potřeba.

Teď tomu tak trochu nerozumím – říkáš, že 0.8 bude v archívu a jak v tomto vlákně, tak jinde lidem, kteří používají 0.8 doporučuješ, aby u ní zůstali, pokud nehledají něco nového. Pro ně by ale přece dokumentace pro 0.8 někde být měla, ne? Pak by měla být pro lidi s 0.9. A potom by mělo být něco jako devel verze, do které budeš házet (z ní mazat) co se ti zachce a dokumentaci nebudeš muset moc řešit, protože tu verzi nebudeš oficiálně podporovat jako stabilní.

Myslím, že něco podobné tomu postupu z Debianu by se do Nette mělo dostat a mělo by to postihnout jak zdrojový kód, tak dokumentaci. Vážně si představ nováčka, který na stránky Nette zavítá. Něco si stáhne, zkusí – hezké, napíše si web (to mu bude trvat třeba 2 měsíce) přičemž během té doby neudělá žádnou aktualizaci, protože to prostě nepotřebuje – vše mu běhá, jak má. Před vydáním narazí na něco, co předtím nepotřeboval (nebo si myslel, že je mu to jasné). Tak tedy mrkne do dokumentace – aha, ono tohle se dělá jinak (předtím se to třeba dělalo tak, jak to zkoušel, ale protože dokumentace je nová a jeho Nette staré, nejde to dohromady). Zkusí použít tu informaci z dokumentace, to ale taky nefunguje, protože v jeho staré verzi není to, co se v dokumentaci uvádí. Dobře, tak si řekne, že je prostě nová verze – udělá update a hle – přestane mu fungovat téměř celá aplikace, protože použil něco, co bylo vyhozeno nebo naprosto předěláno :D. Teď by mě zajímalo, kde takový chudák najde informace o tom, jak to má buď udělat ve staré verzi, nebo jak předělat jeho kód na novou verzi. Mě osobně by se zamlouval postup asi takový:

1. Současnou 0.8 prohlásíme za stable a udělá se přesně pro ní dokumentace.
2. Úplně nové featury se začnou tvořit v unstable (development?) větvi, ke které nemusí být dokumentace, měl by postačit Changelog).
3. Jakmile se dodělá 0.9 do úrovně, že je použitelná, prohlásí se za testing (už se do ní nebude nic přidávat ani z ní nic odebírat) a začne se přesně pro ni tvořit dokumentace.

Na stable a testing větve se budou dělat záplaty kvůli překlepům atp (však to známe všichni), ale nebude so do nic nic přidávat ani z nich nic odebírat.

4. Ta development verze jistě časem dojde do stádia, kde je teď 0.9, takže proces by zafungoval tak, že stable (současná 0.8) i s dokumentací se přesune do archivu. Stable místo přijme současná 0.9 a testing dostane v té době aktuální development větev.

Myslím, že je to docela průhledné a použitelné, co myslíš ty, Davide? ;).

>

ad prepare<View> – obecně chyba a přesměrování může nastat kdykoliv. Na výstup se totiž něco posílá až po zavolání render<View> (tedy pokud aplikace sleduje obvyklý životní cyklus). Z toho důvodu by třeba nastavování hlaviček Content-Type mělo být až na konci render<View>, ideálně přímo v šabloně. Proto myslím, že eleminace prepare v těchto věcech dělá více jasno.

To o chybě v průběhu foreach v rámci šablony jsem se snažil naznačit už v mém postu. To je samozřejmě věc, které se nedá utéct. Pokud to tedy je tak, že skutečné renderování („vykreslení“, tedy „odeslání prohlížeči“) se má dít až po render<View>, tak by logicky vzato spíš ta metoda prepare<View> měla zůstat a render<View> by se mělo zrušit, protože k odeslání prohlížeči se tedy dělá jinde.

ad Content-Type v šabloně – to je zajímavá myšlenka (pokud šablona tuší, jak se má vracet – např. RSS šablona (application/xml), XHTML šablona (application/xml), HTML šablona (text/html), tak by bylo dobré to nějak rozumně zařadit přímo do šablony – takový úvodní blok v šabloně, který by se načetl a takovéto informace by se z něj zjišťovaly (pokud by to bylo jen kvůli Content-Type, tak by to byl trochu overkill, ale zajímavá myšlenka to je ;)). Na druhou stranu jsou chvíle, kdy mám presenter, který šablonu nepotřebuje a vůbec ji nerenderuje – např. věc, která se připojí k DB, vytáhne z ní binární data a ty vybleje uživateli (tam by šablona byla na 2 věci ;)); mám dokonce dojem, že tenhle případ použití se tady ani nikde neřeší :D. Když nad tím tak přemýšlím, jak bys ten Content-Type nastavil z šablony? Pomocí $this->getHttpResponse()->setContentType() nebo je na to nějaká super proměnná přímo pro šablonu (pokud jo, byla by to novinka o které se také nikde nepíše :D)).

David Grudl napsal(a):

m0t3jl napsal(a):

1. Současnou 0.8 prohlásíme za stable a udělá se přesně pro ní dokumentace.

Ono se to lehko řekne „udělá se přesně pro ní dokumentace,“ ale ono to znamená, že si na měsíc sednu a budu psát dokumentaci. Což ostatně budu, mám na to vyhrazený celý srpen. Ale když už ji budu psát, tak rovnou pro 0.9, kterou do té doby chci dotlačit do verze testing.

Můžu ti dát v mnoha věcech za pravdu, ale prostě realita je neúprosná.

ad Content-Type v šabloně – to je zajímavá myšlenka (pokud šablona tuší, jak se má vracet

Spíš si říkám, kdo jiný by to měl tušit. V šabloně proto můžeš použít makro {contentType text/html}

Jak jsem psal – buď to tuší ta šablona (v případě, že se používá), nebo to tuší sám presenter (resp. view), pokud šablona není ;).

Nemusíš plnit tu mou vizi do puntíku, nicméně to ber jako takový hlas prozřetelnosti (:D), jednou to prostě musí přijít. Myslím, že by verzováním dokumentace taky odpadlo dost dotazů tady na fóru, který jsou přesně na tohle zaměřený – něco se změnilo, v dokumentaci to není, a bohužel ne každej nahlídne do kódu. Fórum by se pak konečně věnovalo těm velkým věcem :).

Jasně, ta „sláva“ stojí za to vždycky. Davidových 15 minut slávy trvá už… no… jak dlouho tu máme Nette, Texy a Dibi? :D