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ě. To by mu ovšem rodiče museli dát nějaké lépe zapamatovatelné.
Jestli jste někdy řešili nasazování aplikace, asi víte, že všechno odladit může být celkem zdlouhavá záležitost. Dokážete si představit, že na to máte jen týden? Že je to nemožné? Není! Jde to a ani to nemusí být příliš složité.
Reportáž z virtuální konference FOSDEM. Minule jsem popsali Go room, dnes se věnujeme monitoringu a observability.
Mikrofrontendy jsou zajímavá adaptace konceptu microservices pro potřeby frontendového vývoje. Podívejte se, co to v praxi obnáší a proč jsme se v Seznam.cz rozhodli vyvinout náš vlastní microfrontend framework, Merkur.
more
david je best ma dobry flow, skills, dava dobre freestyly ma dobre produkcie proste je to pan
Problem MVC
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?
Re: Problem MVC
Nevim jestli jsem to pochopil spravne, ale v cem vam nevyhovuje Observer-Observable?
Re: Problem MVC
S výhodou lze použít eventbus – model (nebo kdokoliv jiný) vyvolá událost a kdo chce ať si jí naslouchá a podle toho koná, čili jednotlivé komponenty o sobě nemusí vůbec vědět (loose coupling). Tato konkrétní implementace má i speciální podporu pro Swing, která zajišťuje doručování událostí ve správném vlákně.
Re: Problem MVC
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).
Re: Problem MVC
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.
Re: Problem MVC
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.
Re: Problem 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. ;)
Re: Problem MVC
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.
Re: Problem MVC
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.
Re: Problem MVC
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.
Re: Problem 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.
Rozdeleni modelu a prezenteru
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..
Re: Rozdeleni modelu a prezenteru
Ano, $money je přenášena v url. Ovlivňuje se to pomocí té anotace @persistent. Složitější objekty bych uchovával v session.
Re: Rozdeleni modelu a prezenteru
> 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.
Re: Rozdeleni modelu a prezenteru
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.
Volání funkce revoluční jako znovuobjevené?
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.
revolucni myslenka?
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.
Re: revolucni myslenka?
>>Tohle ale mely Ruby on Rails ohodne driv.
A co jako? Pan Grudl snad psal ze to ma Nette prvni?? Nechapem
Re: revolucni myslenka?
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í".
Re: revolucni myslenka?
Mojavi (2003) – vychazi z neho Agavi a na Agavi zaklada routing Symfony…
Re: revolucni myslenka?
To se vubec neda s Nette srovnat. Staci se podivat jak se v Mojavi verze 2 (rok 2004) otrocky sklada URL http://www.peterrobins.co.uk/it/mojavitutorial2.html#mozTocId492691. Princip, ktery ma Nette, zacalo mit az Symfony, PRADO od verze 3.1.1 (rijen 2007) a ASP.NET MVC (listopad 2007).
Re: revolucni myslenka?
A ted mi prosimte rekni jak to delalo Nette v roce 2004 kdyz se to neda srovnavat? :)))
Re: revolucni myslenka?
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 :)
Textové popisky v controlleru?
Myslím, že controleru můžou být textové popisky ukradené a že by je měl řešit view. Na čí straně je nepochopení? Nebo jsou možné oba přístupy?
Význam URL
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=5by bylo v pořádku. Naproti tomu?coin=5&do=insertvyjadř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$moneyukládala třeba v session proměnné, tak by reload stránky vedl k nepřípustné změně tohoto stavu.Re: Význam URL
Ty mi tady vyzrazuješ obsah příštího dílu! :-)
Re: Význam URL
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).
Re: Význam URL
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.
Re: Význam URL
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 :-)
Re: Význam URL
Říká se tomu REST.
RE: Nette Framework: MVC & MVP
Ja bych mnel dotaz stran te kvalitni brazilske kavy!
Trygve Reenskaug
"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 ;)
RE: Nette Framework: MVC & MVP
Ja teda v "presenteru" nevidim jediny rozdil oproti controleru. Jaky je duvod pro tohle oznaceni oproti standardnimu nazvoslovi?
RE: Nette Framework: MVC & MVP
> Ja teda v "presenteru" nevidim jediny rozdil oproti controleru
V Nette má view úzkou vazbu na presenter. Podle mého názoru je zvolené názvosloví správné.
RE: Nette Framework: MVC & MVP
Ano a taky má úzkou vazbu na model. Opravdu kvalitní odpověď.
RE: Nette Framework: MVC & MVP
Lehký nástin rozdílů mezi MVC a MVP jsem udělal tady: http://rarous.net/weblog/236-mvc-unit-testy.aspx
RE: Nette Framework: MVC & MVP
Zkusím to ještě jednou a trochu obšírněji:
> Ja teda v "presenteru" nevidim jediny rozdil oproti controleru
V Nette má view úzkou vazbu na presenter, čímž se liší od controlleru ve webovém MVC modelu, kde view většinou o controlleru vůbec neví. Alešův odkaz rozdíl pěkně demonstruje.
RE: Nette Framework: MVC & MVP
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…
RE: Nette Framework: MVC & MVP
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.
RE: Nette Framework: MVC & MVP
Zajímavá implikace. Bohužel nepravdivá.
RE: Nette Framework: MVC & MVP
Můžete být konkrétnější v čem je nepravdivá?
RE: Nette Framework: MVC & MVP
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á.
RE: Nette Framework: MVC & MVP
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?
trygve
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.
Re: trygve
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. :-)
Kde se vzala struktura?
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
htmlSpecialChars?
Co je to htmlSpecialChars($display)? Proč to tam je, co to zobrazí a kde je to definované? Díky
Re: htmlSpecialChars?
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:
Ti vytvoří pro šablonu právě tu proměnnou $display:
Můžeš si zkusit přidat do metody buy() pod řádek
a pak do šablony přidat třeba:
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