Názory k článku
Nette Framework: Refactoring

1. Nemuzu si pomoct, ale "drzet" stav mincovniku a jednotlive akce resit pomoci GETu i pres tvoje argumenty mi prijde jako zhuverilost. Chapu ze je to pro priklad, ale...
2. Proc upravovat zobrazeni dat v controleru? Jednak pripadna lokalizace se bude hledat po celym kodu a jednak to nejde koncepcne moc dohromady pro vic moznych verzi zobrazeni(html, xml, json...). Jestli v tomhle spociva "presenter" tak uprimne fuj :P
3. K cemu htmlSpecialChars($display) - v te osekane sablone to snad probuh nedela automaticky ze ne?

ad 3) viz http://nettephp.com/cs/quick-start-6
{$variable} => <?php echo htmlspecialchars($variable) ?>
{!$variable} => <?php echo $variable ?>
atd.

ad 2: Moc otázce nerozumím. Co myslíš tím upravováním zobrazení dat? Předpokládám že controller měl být presenter.

ad 3: pokud myslíš v tom posledním příkladu, tak ano, tam se to (probuh) děla automaticky. Velmi užitečná feature.

Nechci se domýšlet, na co konkrétně vedla otázka, proto se ptám. Co se konkrétně stalo v článku v presenteru takového, že to "nejde moc dohromady pro vic verzi zobrazeni(html, xml, json...)"?

Navíc v dalším pokračováním dokonce dojde k záměně HTML za JSON.

"Co se konkrétně stalo v článku v presenteru takového, že to "nejde moc dohromady pro vic verzi zobrazeni(html, xml, json...)"?"
Odpovím za sebe:
Například:
$this->template->display = 'Málo peněz';
V HTML může být výstup třeba Málo peněz, ale taky třeba JS, obrázek (no dobře, proti tomu lze něco namítnout...), může být potřeba měnit html třídu a další věci. Tato logika by se musela přesunout do Presenteru, kde mi nevoní - je to logika Viewu.
V XML by to mohlo být třeba <error id="not-enough-money"> a podobně v JSON.

"Navíc v dalším pokračováním dokonce dojde k záměně HTML za JSON."
Vyžaduje to manipulaci s Controllerem?
OT: "v dalším pokračováním" není správně - má být "v dalším pokračování". SRY za OT, ale uhodilo mě to do očí.

Tady je jasně definované rozhraní mezi presenterem a šablonou, do nějž patří string $display. Zdůrazňuji, že nijak neupravený pro "předpokládané" potřeby výstupu. Prostě čistý řetězec.

Je pak věcí šablony, jestli jej zobrazí v <p id="display">{$display}</p>, v JavaScriptovém alert($display) nebo třeba XML <error id="not-enough-money">$display</error> (pro tento případ by bylo vhodné rozšířit API o příznak chyby nebo chybový kód).

Řekl bych, že si děláš ve věci zmatek žonglováním s termíny controller, presenter, view a šablona. Controller není presenter, view není šablona. Píšeš "tohle mi nevoní, tohle je logika view" ale hovoříš o šabloně - ptám se, je také to "logika šablony"? Neplatí, že hranice mezi částmi Model-View-Controller kopíruje hranici tříd (nebylo tomu tak ani v tzv. klasickém MVC, kde view a controller implementovala jedna třída).

"Řekl bych, že si děláš ve věci zmatek žonglováním s termíny controller, presenter, view a šablona."
Na tom asi něco bude.

"Neplatí, že hranice mezi částmi Model-View-Controller kopíruje hranici tříd" + "pro tento případ by bylo vhodné rozšířit API o příznak chyby nebo chybový kód"
Někdy je to IMHO vhodnější. Nevoní mi přidávání nějakého stavového kódu v Presenteru nebo Controlleru (tady je to jedno, ne?) jen kvůli tomu, že to chce View?
Pokud to chápu, tak tady se přesouvá část View do Presenteru, aby místo celého View byla šablona.

"nebylo tomu tak ani v tzv. klasickém MVC"
Proti této argumentaci lze použít citaci z http://zdrojak.root.cz/clanky/nette-framework-mvc--mvp/ : "Historický exkurz měl ukázat, jak různorodé bylo pojetí MVC už v okamžiku vzniku. Byla to holt doba pionýrská. Nechápejte proto MVC dogmaticky!"
Pokud jde jen o nějaké "mimochodem", pak budiž.

> Pokud to chápu, tak tady se přesouvá část View do Presenteru, aby místo celého View byla šablona.

Dalo by se říct, že metoda renderDefault() je součástí vrstvy View, společně se šablonou. Takže přesouvání kódu mezi renderDefault a šablonu se děje spíš v zájmu toho, co je vhodné mít v šablonovací logice a co už nikoliv. Ale ať už je to tam nebo tam, vždy je to součást View.

Rovnou odpovím i na otázku, proč tedy presenter nerozdělit na svě samostatné třídy: v Nette to lze poměrně snadno provést, ale nejpozději ve chvíli, kdy se začnou používat komponenty, se to ukáže jako velmi nepraktické. Proto místo dělení na dvě třídy se používá dělení na životní fáze.

> různorodé bylo pojetí MVC už v okamžiku vzniku

Tím "klasickým MVC" se obvykle myslí jeho první implementace. Která původní návrh moc přesně nedodržovala.

No já si teď neumím přesně představit ty problémy, i když možná tuším - počkám, až ukážeš komponenty a pak to rozeberu.
Přiznám se, že Nette se mi původně zdálo divné, ale vypadá to, že všechny ty divnosti mají svůj účel a logické opodstatnění.
A na klasické MVC bych se neodkazoval, když mluvíme o současnosti...

2. Myslel jsem přesně to co psal v6ak. Přeci i tak pracuješ v šabloně s logikou (isset($coffee)), proč tedy mít logiku na dvou místech? ...to není problém frameworku, jen mé pragmatické smýšlení nechápe proč to dělat takhle, když to víc věcí komplikuje...
3. Pokud existuje i varianta {!...} tak samozřejmě ok, jen se chytám toho, že ze spousty "automatických" featur zvětšiny pro začínající "programátory" při pokročilejším programování smrděly problémy.

Tak zkus schválně navrhnout jiné a lepší řešení tohoto konkrétního úkolu. Jaké proměnné dávat do šablony a jakou logiku mít v šabloně.

Spíš než návrh ti napíšu jak to funguje v Symfony. Má taky svoje nevýhody, ale řekněme že funkční kód od šablony odděluje imho velice dobře.

1. Má sloty, což vypadá asi takhle:
layout:
<meta name="robots"><?php if(!include_slot('robots')): ?>index,archive<?php endif; ?>" />
a v html šabloně erroru:
<?php slot('robots', 'noindex,noarchive') ?>

2. Má komponenty a helpery. Šablona komponenty Display (sf_user je v šablone obal okolo session, v akci je pod $this->getUser()) includovaná do layoutu:
<?php echo $sf_user->hasMoney() ? format_currency($sf_user->getMoney()) : __("Insert coins") ?>

3. A z akce v controleru ti zbyde např. jenom
executeBuy() {
if(!$this->getUser()->buyCoffie()) return sfView::ERROR;
}

Ve finále máme čistej controler, logika html šablon je čistě v šablonách, můžu si navymýšlet šablony pro xml i json aniž bych musel šáhnout do "funkčního" kódu.

Díky, takto je to mnohem názornější.

Ve své podstatě se snažíš veškerou zobrazovací logiku přenést do šablony. V případě chyby se použije jiná (error) šablona, o obsahu displeje rozhoduje šablona na základě surových dat z modelu.

Po technické stránce lze totéž udělat i v Nette (jen místo "slotu" je "block", helper zůstává helperem a "return sfView::ERROR" se nahradí za "$this->setView('error')"). Rozdíl zůstává v rovině řekněme filosofické.

Namítl bych, že jsi do šablon umístil nikoliv "logika html šablon", ale "logiku celého view", ačkoliv šablony jsou jen podmnožinou view. Tohle se mi nelíbí. V tomto konkrétním případě mi také vadí duplicita šablon, existence cca stejných šablon automatu lišících se jen hláškou na displeji.

O "čistej controller" tady nejde - v Nette je kontroler víceméně součástí frameworku a controller != presenter. Presenter na sebe bere břemeno udržet čisté šablony a udržet také čistého sám sebe.

V praxi je jednodušší zadat kodérovi výrobu šablony s tím, že "v této proměnné je obsah displeje, v této indikátor chyby, atd.", než "tady najdeš cenu nápoje, tady obsah mincovníku a v tomto dokumentu je popsána logika, kterou musíš respektovat". Nebo ne?

No, můj způsob práce je co nejvíc oddělit formu zobrazení a kód, který manipuluje s objektama před zobrazením(ať už tomu říkáme jakkoliv) abych si mohl se šablonama dělat co chci a v kontroleru mi zase nerušily řetězce. Ty budeš takhle asi vždycky vázán na presenter, který s jinou formou prezentace budeš muset měnit. Já si v routování akorát nastavím "koncovky" šablon - a mám z výstupu instantní rss, json atd. Jestli správně hádám tak ty vytvoříš buď další presenter(opakující se nebo nadbytečný kód) nebo budeš nastavovat šablonu podle nějaké proměnné(budeš směšovat kód pro různé šablony)...

Nicméně máš pravdu, s kodérem to budeš mít mírně jednoduší ty, já bych teda z nich nedělal přímo cvičené opičky...s lehčí nápovědou taky lecos pochopí :)

To, co se v Symfony nazývá akce, je v Nette rozdělené na akci a view. Metoda renderDefault patří k view a plní obvykle podobnou funkci jako Code Behind v ASP.NET (prostě věci, které se člověku nechce dávat do šablony, ale přitom je to pouhá prezentační logika).

Pokud by k akci chtěl přidat další view, tak by přidal pouze další renderNěco metody, ve kterých by si data upravil pro jiné šablony (při použití push šablon), kód samotné akce by se neopakoval. Akorát by teda do akce musel přidat nějakou logiku pro výběr view, třeba na základě parametru z routy, např:

public function actionDefault($view = "default")
{
    // Logika akce, tj. controlleru
    // ...

    if (in_array($view, array("default", "rss"))
    {
        $this->view = $view;
    }
}

Viz http://nettephp.com/cs/action-vs-view

Chtěl jsem se zeptat, v jakém SW vznikl "Životní cyklus presenteru" - tedy obrázek: http://i.iinfo.cz/urs/nette-401-123844392320589.gif ?
Experimentoval jsem s ArgoUML, ale to tak hezky nestínuje.
Omlouvám se za OT k tomuto článku.

To je kombinace stařičkého Corelu a bitmapového editoru pro přidání stínu ;)

Podobne obrazky lze relativne snadno tvorit v OmniGraffle (Mac-only, sorry ;-)) - velmi doporucuju.

Ak náhodou nie si nejaký geroj, čo sa zamestnal v nejakej firme, berie pravidelne plat za to že obetuje svojmu zamestnávateľovi X hodín zo svojho bezvýznamného programátorského života tak by tento tvoj komentár mohol mať aj nejakú výhu, v opačnom prípade músim skončtatovať, že je podstatný rozdiel medzi životom robotníka v kompromise a životom človeka ktorý "riadi". Hlavne je tak trochu trápne mu dávať nejaké rozumy. Ja osobne mám väčší rešpekt voči ľuďom ktorí sa nad vecami zamýšľajú a rišenia prinášajú ako nad tými ktorí ich "iba" akceptujú. S týmto súvisí aj môj obľúbený citát o (priemyselnom) dizajne. "Design is about how something works, not how it looks. It's what's inside that counts.
The best designs are the result of someone's questioning everything around them." (James Dyson) Treba sa občas snažiť aj o veciach premýšľať. Nie sa na ne iba slepo adaptovať. Hlavne v prípade ak človek chce niekam pokročiť vo vývoji.

Každý framework se hodí na něco jiného. Že se podle Vás nehodí Nette na projekt na 30 člověkolet, to je docela dobře možné. Uvědomte si ale, že takových projektů je ze všech vznikajících webů sotva půl procenta (Zdroj: vycucáno z prstu).

Nette může být naopak mnohem lepší/jednodušší/snažší na údržbu a na kvalitu zdrojáků pro 80 % projektů.

Nechci a nebudu tady kopat ani do Springu, ani do Nette. Každý framework má to svoje. A brečet, že se assembler nehodí na kódování webu a ruby na programování operačních systémů (nadsázka), to je prostě zcela mimo.

Přece jen segment menších webů je celkem velký na to, aby i pro nějmohli existovat frameworky, ktere jejich vyrobu zefektivní. Na ty velke tu jsou pak pracanti jako vy.

Cele PDF jsem poctive precetl a prekvapilo (a samozrejme povzbudilo) me to, ze je to Spring MVC, kdo by se mohl od Nette hodne ucit. I kdyz je otazka jak moc je ten dokument vypovidajici, protoze treba o MVC jsou tam velmi chybne informace. Ale nechci se prit, kdo je nebo neni lepsi, je to proste muj dojem.

namiesto nekonkretnych blabolov by ste obaja mohli prejst k samotnemu boxu.. teda ak je na to vola.. prednost by mohol mat obhajca springu.. nech sa paci ;)

Ano, ano, přesně to tvrdím a skromnosti mám doufám přiměřeně. Nepleťme si skromnost a pokoru. Tu jsem v reakci na váš komentář odhodil, i když chápu, že jste to myslel v dobrém, nicméně jsem chtěl být také provokativní. Ovšem argument "jak by něco lokálního mohlo být v jakémkoliv směru lepší než to, co vytvořill člověk s anglickým jménem", ten rozhodně neberu ;)

Pokud bychom skutečně chtěli oba frameworky srovnat, musí se to odehrát konstruktivně, v rovině rozumných argumentů - já jsem pro a klidně začnu.

První a nejdůležitější věc - nika Javy a PHP se téměř neprotíná, tyto jazyky si téměř nekonkurují. Dosud tu není plnohodnotná platforma pro hostování Javy stylem ověřeným pro PHP, stejně tak PHP nemá žádnou enterprise edici. Tudíž ani frameworky si nekonkurují a nelze říct "k čemu kvalitní framework pro PHP, když existuje Java a Spring?".

Srovnání začnu od Modelu, protože to je oblast, kterou Nette záměrně přenechává jiným knihovnám. Důvod je ten, že způsob "class diagram = E-R diagram = formulář", je sice na pohled hodně elegantní a dnes i populární, ale s praxí se překrývá jen v 80-90 % a zbývající procenta se strašně těžko pokrývají. Nette hledá jiné cesty, viz třeba http://phpfashion.com/mvc-paradox-a-jak-jej-resit.

Vedle toho controller a view můžeme velmi dobře porovnat. Podle odkazovaného PDF jsou oba frameworky v mnoha směrech velmi podobné, zaměřím se tedy na rozdíly:

- URL vrstva: zatímco Nette Framework ji zcela odděluje, Springu je s URL úzce svázaný. Díky tomu jsem mohl třeba před dvěma týdny přídáním JEDNOHO řádku http://jdem.cz/a6gq7 dosáhnout toho, že tvar všech URL v demonstrační aplikaci se dynamicky změní podle konfigurace serveru. Ve Springu by podobný efekt (opět vycházím z PDF) znamenal změnu na mnoha místech kódu kontroleru a šablon.

- kontroller: ve Springu se jim může stát jakákoliv třída, v Nette musí implementovat interface IPresenter. Je to rozdíl, ale nedokážu jej zhodnotit. Fungování metod s parametry je v obou frameworcích prakticky totožné. Předávání návratových hodnot naopak Nette nemá.

- view: odvození jeho názvu a namapování na šablonu je opět velmi podobné, jen Nette se vyhýbá konfiguraci v XML. Podobná je dokonce i syntaxe šablon. Z PDF těžko říct, který jazyk je v praxi silnější, jak to funguje v Nette uvidíte v příštím díle.

- validace dat: Nette věc pojímá trošku jinak, ale nějaký zásadní rozdíl v tom nevidím.

- odkazování: opět to souvisí s oddělenou URL vrstou, takže místo return "redirect:nejake-url.do" ve Springu se v Nette odkazuje přímo na název metody kontroleru, tj. $this->redirect('metoda'); V tom vidím zásadní přínos, místo, kde by se Spring mohl inspirovat.


Suma sumárum, Spring MVC vypadá jako velmi dobrý a šikovný framework. Nevidím ale nic, kvůli čemu bych měl padnout na kolena a opustit Nette. Naopak řada vlastností by mi chyběla.

To hore som ja :-)

Este mi napadlo: ktore vlastnosti by vam chybali?

Mna primarne zaujalo to generovanie formularov spolu s JS validaciou. To vyplyva z generovania formularov cez PHP.

Co by mi chybělo? Ze zmíněných věcí asi ta oddělená URL vrstva a pohodlné generování formulářů, které stačí jednou popsat jazykem PHP a automaticky se vygeneruje HTML, JavaScript a provede validace na straně serveru.

Naopak uživatelům Springu by asi nejvíc chybělo propojení s modelem a databázi.

Ono se na to těžko odpovídá, protože Spring jsem viděl jen z rychlíku, přitom sílu frameworku člověk pozná, až když s ním pracuje.

Ale: Spring MVC absolutne neriesi, v com bude napisany view. JSP? Freemarker? JasperReports? RSS? Staci, ze view rendered dostane modelovu mapu a ako ju zrenderuje je na nom. Nette podporuje primarne PHP, ako je to s inymi vrstvami?

Podobně to funguje i v Nette. Zítra by měl vyjít další díl seriálu, který se týká právě renderování šablon, takže tam to bude popsáno podrobně.

Kontroler. Spring MVC razi zasadu, ze obsluzne triedy maju byt jednoduche, najlepsie bezne triedy s anotaciou. (Anotacia je ekvivalentna marker interfacu bez metod).

Anotace PHP prakticky nezná. Zkusil jsem s nimi přijít v Nette, ale narazilo to na technické a „filosofické“ problémy, takže se držím zpět ;)

Odkazovanie. „redirect:“ je skratka pre pohodlnych. Pokojne mozete vratit specialny RedirectView, kde uvediete logicke meno viewu a model (presny ekvivalent „->redirect()“).

Tady mi šlo spíš o ty URL, které Nette generuje dynamicky. Tedy ačkoliv když vrátím RedirectView, tak se jich nezbavím. (teda jestli to dobře chápu).

Tu by som podotkol, ze netreba mat totalnu paranoju z XML. Bezna springova aplikacia ma aj tak XML subor pre dependency injection, cize tam je to jedno.

Ano, to je věc zvyku. Ve světě PHP jsou preferovanější INI soubory, nejspíš proto, že samotné PHP se tímto způsobem konfiguruje.

(a pozor: DI je velmi dobry pattern, ktory vyvoj velkych aplikacii sprehladnuje).

Bezpochyby!

ako je mozne pouzivat vlastne formulare (Nette generuje kod formularov dynamicky, toto Spring MVC nema, view vrstvu nechava na vyber implementatora)

V podstatě lze volit v řadě úrovní od prostého manuálního vykreslení a obsluhy formuláře až po plně automatické v režii objektu Form (například automatická obsluha + manuální vykreslení v šabloně). Asi největší vývoj probíhá na straně automatického vykreslování, protože je to pohodlné (čti: uživatelé to chtějí), ale zároveň by to mělo být co nejlépe konfigurovatelné (čti: každý formulář vypadá úplně jinak).

Poctivo prechadzam serial a coraz viac dochadzam k nazoru, ze Nette mi nebude sediet ( co je obrovska skoda, veci ako Object alebo Ladenka su genialne). Vadi mi MVP paradigma, ktore Nette pouziva.

V tejto casti sa definoval novy view, ale bohuzial ked kukam na kod presentera, nedokazem z kodu „handle“ fnci urcit co sa bude renderovat. Vadi mi, ze v app je viac Views a napr. ked pozeram na kod handleInsert() nedokazem povadat co sa bude diat po zavolani $this->redirect(‚this‘) – co sa vykresli.

Ako uz hore niekto pisal, spojenie logiky P a V nie je good. A skutocne. Prechadzam aj ten diagram, ale nie som schopny urcit, kde a aky View sa pouzije.

V ZF je toto IMO omnoho logickejsie. Je jediny View. A na zaklade dispatchingu sa vykona nejaka akcia a k nej zdruzena sablona sa preda do toho jedineho View. Velmi podobne je to v Symfony.

Aha, pozeram, ze aktualny view je mozne odvodit zo sablony pomocou tych (ne)vykricnikov v odkazoch $presenter->link().

Hodilo by se, kdyby byl na konci zobrazen vždy nějaký ucelený kod nebo možnost stáhnout kompletní projekt. Někdy se ztrácím co je model,presenter a o jaký presenter se jedná.

asi to je otazka odveci a ani niesom niejako zvlast dobry v kodeni no ale stala sa mi taka veci zmenil som subor model v dokoncenom projekte teda ked som ho robil sam neslo to ladenka mi davala chybu :InvalidState­Exception
Cannot set HTTP code after HTTP headers have been sent (output started at /domains1/do2538000­/public/www_ro­ot/CoffeeVendin­gMachine/app/mo­dels/Model.php:1).
akvsak zlvastne je natom to ze:1, prava su ake maju byt,
kodovanie suboru je utf8
zmena bola napr z const COFFEE_PRICE = 10; na const COFFEE_PRICE = 30; staci ze znamem 1 a dam 3 a uz je to tam ladenka to hodi a ak prekopirujem z povodneho rozbaleneho projektu subor model.php uz to ide a potom znovan napr len zmazem a s5 napisem 1 aby akoze prebehla zmena v subore a ladenka hodi tu chybu, prosim vas mozete mi niekto stym pomoct o co tu ide? budem fakt vdacny a ospravedlnujem sa ak to nieje vhodne vzhladom na temu alebo je to hlupa utazka.