Názory k článku
Nette Framework: MVC & MVP

david je best ma dobry flow, skills, dava dobre freestyly ma dobre produkcie proste je to pan

Muj problem s MVC pristupem je ten, ze casto je velmi spatna podpora aktivni komunikace ze strany modelu k view. Zni to jako paradox, ale proste se jedna o klasicky pripad, kdy treba mam v GUI tabulku s daty (ted mam na mysli klasickou, ne-webovskou aplikaci) a model je navazany at uz na databazi nebo treba zobrazuje obsah slozky. Treba ve Swingu je docela porod, aby model notifikoval (vsechny) pohledy, ze doslo ke zmene - protoze holt MVC ocekava, ze veskere zmeny modelu budou iniciovane z controlleru.

Nebo proste jenom nevim jak na to?

Otázkou je, zda má zde popisovaná knihovna Nette nebo i Swing ve svých widgetech a view pro zpracování událostí (nebo pattern Observer) podporu.

Osobně si myslím, že v uvedeném příkladu by bylo možné Model a Presenter sloučit. Podle mého chápání MVC oba představují model. Bohužel ale postrádám právě pattern observer, který by zde měl sloužit k notifikacím View, když se změní proměnná $money. Právě proto je potřeba ručně v kodu sáhnout do template a změnit hodnotu (metoda insert).

O tom sloučení by to nebyl zas až tak dobrá nápad, protože to je ta halvní výhoda tohoto návrhu, logika automatu je v Modelu, ale její prezentace v Prezenteru, a když budu chtít změnit například jazyk automatu, vyměním pouze prezenter a nechávám model.

Pořád ten důvod nevidím. V uvedeném případě je chování automatu natolik jednoduché, že by bez problémů šlo do vložit do třídy Prezenter. Pokud by mělo dojít ke změně, patrně bych třídu Prezented upravoval (ve vašem příkladu bych změnil patřičné texty). Pokud by šlo o větší změnu (možnost fungování automatu v různých jazycích), použil bych nějaké sofistikovanější řešení (opět na příkladu jazyka by to bylo nejspíš na bázi překladových katalogů).
Ano, rozumím, že logika fungování automatu může být složitější a bude se muset skládat z vlastních tříd a datových objektů, které mezi sebou budou komunikovat. Tyto objekty pak budou tvořit datový model, což je ale jiný pojem než Model v návrhu MVC.

Klasický problém programátorů. Všechno jde napsat odzhora dolů. Otázka, je, jak je to udržovatelené a znovupoužitelné. Principy dobré objektového návrhu tu nejsou pro nic za nic. ;)

Nejspíš se příliš zaobírám popsaným příkladem. Mým cílem bylo a je říct, že chování automatu, popsané v uvedeném příkladu třídou Model, je datovým modelem, což je něco jiného než "model" v definici MVC. Definici modelu splnuje třída MachinePresenter (představuje model chování automatu pro uživatele).
Problém, který pak v příkladu vidím, je těsná vazba modelu na view (metoda insert), což je přesně to, čemu se MVC model snaží vyhnout.

Model z ukázky rozhodně odpovídá definici modelu v architektuře MVC (a asi by v něm měla být i proměnná $money) a MachinePresenter je zase typickým presenterem v architektuře MVP. Podle mého názoru je ukázka v pořádku.

Nette je psane v PHP pro webove pouziti. Nacteni novych informaci bude iniciovano uzivatelskou akci v prohlizeci, o nejakem sledovani pohledu ze strany modelu nemuze byt asi rec.

Ve vseobecne rovine muze jit o problem implementace MVC, ktera, jak David naznacil, stale neni idealni. Kazdemu vyhovuje jiny styl a take proto vznika spousta MVC frameworku. Ustalena pravidla v ramci architektury mohou byt pro vyvoj aplikace omezujici a tak se casto hledaji klicky a vyjimky pro implementaci specifickych funkci. Robustni MVC systemy se sirokou skalou funkci mohou byt slozite na nauceni, jednoduche MVC systemy zase predpokladaji vetsi zasahy do kodu aplikace ze strany programatora, a tim padem i hlubsi pochopeni kodu a logiky MVC.

Mozna se ptate na metody zacinajici na fire... Napr u AbstractTableModel je napr fireTableDataChanged(), ktera notifikuje vsechny pohledy na tento model, ze se data v tabulce zmenila a maji se prekreslit.
Takze modelu predate nova data a pak zavolate fireNeco podle toho, jaky rozsah chcete obcerstvit (pokud neresite vykon, tak vzdycky vsechno :-) ) a o vic se nemusite starat. V idealnim pripade si aplikace vubec nemusi drzet odkaz na zobrazovaci tridu pote, co ji preda model, vsechno se to obstara vnitrne ve swingu.

Zajimave, ale nejsou mi jasne dve veci.

Prvni vyplyva z me neznalosti NETTE frameworku. Jak je uchovavana hodnota instancni promenne $money mezi jednotlivymi kliky? Je zakodovana do URL? Jakym zpusobem je mozne ovlivnit, ktere promenne se maji uchovat a ktere ne? Jak je to s uchovavanim slozitejsich datovych struktur? (pole, slovniky, jine objekty)?

Druha otazka se tyka volby rozdeleni zodpovednosti automatu na kavu mezi model a presenter. Ocekaval bych, ze presenter ma na starosti pouze interakci mezi modelem (tj. fyzickym strojem na kafe) a uzivatelem, tj. v pripade analogie s fyzickym automatem ma prezenter roli predniho panelu s navodem k pouziti, tlacitky, mincovnikem a vydejovym okenkem, ale _nemel_ by jiz resit vnitrnosti stroje, tj. rozhodovaci logiku zda uzivateli vydat ci nevydat kafe podle toho kolik do nej bylo nahazeno penez atd, vareni kafe, uchovavani informaci o tom kolik penez je v mincovniku atd.. V objektovem modelu by podle me mel mit prezenter pouze jedinou instancni promennou, $model, ktere by posilal zpravy jako coinInserted, coffeTypeSelected, getCoffeeMakingProgress, ale veskera obsluzna logika by jiz mela byt v modelu. Pokud zacnete cpat business logiku z modelu do presenteru, veskere vyhody MVC se vytraceji.
Koukam ze to nebyla ani tak otazka, jako spis konstruktivni kritika :)


Jinak framework pusobi vcelku rozumne, dalsi maly krucek k zjednoduseni tvorby webaplikaci..

> tj. v pripade analogie s fyzickym automatem ma prezenter roli predniho panelu s navodem k pouziti, tlacitky, mincovnikem a vydejovym okenkem, ale _nemel_ by jiz resit vnitrnosti stroje, tj. rozhodovaci logiku zda uzivateli vydat ci nevydat kafe podle toho kolik do nej bylo nahazeno penez atd, vareni kafe, uchovavani informaci o tom kolik penez je v mincovniku atd.


Ano, rozdělení odpovědnosti je velmi důležitým bodem návrhu MVC aplikace. Tedy zodpovědět otázku, co je "prezentační logika" a co "byznys logika". V uvedeném příkladu ve své jednoduchosti lze rozhodnout tak i tak, obojí bude správně a mně se toto rozdělení lépe hodilo do příkladu.

Jako zásobník na mince, který uchovává informaci, kolik mincí v něm je, si lze totiž analogicky představit třeba "zásobník na písmenka s uchováváním informace", neboli [input type="text"]. U něj by asi nikdo neváhal, že patří do prezentační logiky.

Jako zásobník na mince, který uchovává informaci, kolik mincí v něm je, si lze totiž analogicky představit třeba "zásobník na písmenka s uchováváním informace", neboli [input type="text"]. U něj by asi nikdo neváhal, že patří do prezentační logiky.

Nevidim zadnou analogii mezi zasobnikem na mince a retezcem("zásobníkem na písmenka s uchováváním informace"), krome toho ze oboje bude zrejme reprezentovano jako kolekce objektu.

Nevim proc bych nemel vahat jestli patri retezec umistit do prezentace nebo byznys logiky, to mi prijde jako dost dulezite a netrivialni rozhodnuti zavisle na tom co modeluji. Jinak samozrejme _vzdy_ lze dat logiku do modelu nebo do prezentace, ale v zavislosti na konkretnim pripade ma jedno nebo druhe lepsi smysl, usnadnuje nebo ztezuje porozumneni a navrh aplikace. Se zbytkem souhlasim.

Nechci shazovat hlavní myšlenky autora, ale dispatcher na funkci (odkaz coby zavolání funkce) mělo už cherrypy 2 (http://cherrypy.org/) se kterým jsem pracoval už pár let nazpět.

A vsadil bych se, že určitě nebylo první, kdo s timhle konceptem přišel.

citace: na jehož počátku byla (dnes si troufám říci) revoluční myšlenka: nechť je odkaz totéž, co zavolání funkce.

Tohle ale mely Ruby on Rails ohodne driv.

>>Tohle ale mely Ruby on Rails ohodne driv.
A co jako? Pan Grudl snad psal ze to ma Nette prvni?? Nechapem

Rozhodně nechci hájit nějaké prvenství, toho jsem dalek. Jen mi v roce 2004 žádný podobný koncept nebyl znám (Rails v té době neexistovali, u výše zmíněného Cherrypy se mi z dokumentace nedaří zjistit, zda umí ovlivnit tvar URL, ale možná jen špatně hledám). Vím, že dnes existuje řada více či méně podobných řešení (např. ASP.NET MVC), dost možná existovaly i před Nette, ale v roce 2004 se prostě o podobných věcech nepsalo a nevědělo, proto to slovo "revoluční".

A ted mi prosimte rekni jak to delalo Nette v roce 2004 kdyz se to neda srovnavat? :)))

s ASP.NET MVC jsem se nedávno dostal do styku a když jsem v něm zkoušel cvičně programovat pár miniaplikací, nemohl jsem se ubránit dojmu, že buď mohutně opisoval Nette od Asp.NET MVC a nebo naopak. Obojí je samozřejmě blbost :)

Docela by mě zajímalo, jestli je schopný se asp.net mvc v budoucnu prosadit.
Jinak Nette je skvělý kus kodu, ktery clovek neprivadi do depresi, kdyz uz musi programovat v php. Gratulace :)

URL by mělo vyjadřovat stav aplikace a nikoliv postup, jak jsme do tohoto stavu dospěli. Stav kávomatu je vyjádřen hodnotou proměnné $money, takže URL ?money=5 by bylo v pořádku. Naproti tomu ?coin=5&do=insert vyjadřuje postup. Podle mého názoru by akce provedená na tomto URL měla přesměrovat právě na ?money=5. A to navíc odhlížím od toho, že akce mění stav aplikace, takže by měla být odesílaná metodou POST. Pokud by se hodnota $money ukládala třeba v session proměnné, tak by reload stránky vedl k nepřípustné změně tohoto stavu.

Ty mi tady vyzrazuješ obsah příštího dílu! :-)

No v tomhle pripade si tedy nejsem moc jisty. Jednak nevim, proc by URL melo vyjadrovat stav a ne akci, do URL si snad muzu zakodovat co chci podle toho jak se mi to hodi.. Nevim jestli je to nejaky doporuceny postup, ale v tomhle pripade znemoznuje prihazovani vice lidi do automatu (jdu si dat romanticke kafe do automatu v delvite se svym devcetem, ja mam jen petikorunu a ona taky, kafe stoji 10 tak se dohodneme ze tam kazdy hodime vsechno a pak to jeden z nas vybere a kafe vypijeme dohromady).

- Oba si nacteme stranku kde je pro klik na petikorunu vyjadren jako ?money=5
- Ona prihodi petikorunu, vygeneruje se ji stranka s klikem na petikorunu vyjadrenym jako ?money=10, bohuzel uz petikorunu nema tak ceka na me
- Ja prihodim petikorunu, ale tim jen nastavim cilovou castku zase na 5 korun, prijdu i o sveho bura a kafe si nedame protoze automat si mysli (resp. skutecne ma) pouze 5 korun, petikoruna meho devcete jakoby nebyla (ale je klidne mozne ze se ji odecetla z kapsy! pokud neni implementovan nejaky komplikovany kontrolni mechanismus kdy se ptam automatu jestli se nekam neztratily me penize..)

To asi neni stastne reseni, lepsi by v tomto pripade bylo kdyby do URL byla zakodovana akce a stav byl ulozen jinde (na serveru).

Možná jsem se nevyjádřil srozumitelně. URL na provedení akce by samozřejmě mělo vést na ?coin=5&do=insert (lépe navíc metodou POST). Toto URL by ale nemělo v prohlížeči zůstat a mělo by uživatele přesměrovat na ?money=5 (pokud držíme stav v URL proměnné a ne třeba v session).

Ale počkejme skutečně na další díl - jak mi David objasnil, tak přesně tímhle by se tam měl zabývat.

Ach tak, to jsem skutecne pochopil jinak, takto to jiz dava dobry smysl. Omlouvam se potom za offtopic prispevek (a sobe si nadavam do gorilich klitorisu ze jsem jim ztratil tolik casu misto abych zkusil vic premyslet :-)

Říká se tomu REST.

Ja bych mnel dotaz stran te kvalitni brazilske kavy!

"Když Trygve Reenskaug v roce 1979 popsal architekturu Model–View–Controller (MVC), zapsal se do dějin programování a jeho jméno by měl znát každý vývojář na celém světě."

doufam, ze ho nemusi umet i vyslovit ;)

Ja teda v "presenteru" nevidim jediny rozdil oproti controleru. Jaky je duvod pro tohle oznaceni oproti standardnimu nazvoslovi?

Ano a taky má úzkou vazbu na model. Opravdu kvalitní odpověď.

Lehký nástin rozdílů mezi MVC a MVP jsem udělal tady: http://rarous.net/weblog/236-mvc-unit-testy.aspx

Nejsem si jisty jestli si to pamatuju dobre, ale mam za to, ze na strankach autora bylo nekde napsano ze MVC = MVP (controller = presenter). Je to jenom jiny nazev...

Rozdíl zde je, alespon v chápání Controlleru podle původního návrhu. Tam bylo úkolem Controlleru přebírat události systému (stisky kláves, pohyb a klikání myší) a na jejich základě spouštět akce definované Modelem. U webových aplikací tento úkol prakticky provádí sám browser (občas za přispění javascriptu) a komunikuje s modelem pomocí URL.
Pokud použijeme tuto definici Controlleru, pak je Presenter de facto Modelem.

Zajímavá implikace. Bohužel nepravdivá.

Můžete být konkrétnější v čem je nepravdivá?

Dobře jste poukázal na podobnost mezi původním chápáním MVC a dnešními webovými MVC frameworky, protože ta analogie je tam opravdu velká. Nesprávně ovšem píšete, že u webových aplikací je controllerem de facto prohlížeč: webová aplikace je serverová záležitost a o nějakém prohlížeči nemá ani tušení. "Systémové události" jsou u webové aplikace v podstatě jen jednoho typu: vyvolání skriptu přes HTTP požadavek, takže controller je ve webovém MVC modelu ten kód, který tyto požadavky zpracovává.

Takže pokud správně chápu mohl by být rozdíl v tom, že validace a zpracování requestu je prováděno v modelu?

Mě zaujala ta vtipná hláška z perexu o jménu Trygve. Skvělý začátek prezentace.
Jméno Trygve má 6086 Norů, přičemž v celém Norsku jsou méně než tři lidi se jménem Trygve Reenskaug. Příjmení Reenskaug má 34 lidí.
Na druhé straně, i když je jméno David na žebříčku popularity na 6-7. místě (tedy hodně vysoko), tak příjmení Grudl je v Čechách zastoupeno ve 4 případech (včetně cizinců, zemřelých, nezvěstných :). Tedy méně než Reenskaugů. Ale dá se to prezentovat i tak, že jsi výjimečnější než Reenskaug :)
Každopádně ti držím palce, prezentuj, vysvětluj, zjednodušuj, přibližuj, konkretizuj.

A ta poznámka o elektronce, děrovačce a dřevěné pramyši taky míří tak trochu vedle, jelikož pán pracoval v PARCu, a věřím, že pro zdejší čtenáře k tomu není třeba nic dodávat. :-)

Dobrý den. Je možné že jsem si toho nevšiml, ale kde je řečeno cokoliv o struktuře, bootstrapu a jiných věcech ze staženého automatu?
Ne, že bych tímto šel proti autorovi, ale rád by jsem pochopil proč volit tuto strukturu a proč máme bootstrap když to "můžu" všechno napcat do jednoho souboru

Co je to htmlSpecialChar­s($display)? Proč to tam je, co to zobrazí a kde je to definované? Díky

http://jonatan.spse.pilsedu.cz/doc/php-man/function.htmlspecialchars.html

- slouží pro ošetření výstupu

Pokud jsem to dobře pochopil, s Nette teprve začínám ale myslím si:

$this->template->display = 'Vhoď ' . Model::COFFEE_PRICE . ' Kč';

Ti vytvoří pro šablonu právě tu proměnnou $display:

<?php echo htmlSpecialChars($display) ?>

Můžeš si zkusit přidat do metody buy() pod řádek

$this->template->display = 'Dobrou chuť';
$this->template->odstavec = 'Nový odstavec';

a pak do šablony přidat třeba:

<?php echo htmlSpecialChars($odstavec) ?>

Doufám, že to je správně :) nemám to odzkoušení je pul třetí a už se mi nechce otevírat PsPad :D