Hmm velmi zaujimavy nazor. Mimochodom ako vedlajsi efekt dakujem za ten Freemaker. Toto je nieco co som dlho hladal. Tiez sa mi zhodou okolnosti protivia JSPcka.
Zdenko 2011/7/27 Petr Novak <kek.for...@gmail.com> > ** > Zkusím poslat svůj názor na pojem Controler a jak si ho vykládám a používám > já, bez ohledu na podporu v různých frameworcích. Zároveň nechci tvrdit, že > ten můj pohled je správný, prostě s ním jen takto žiju a zdá se mi to zatím > docela funkční :). > > Můj pohled na aplikaci vychází z pojmu Use Case (UC) - jeden nějaký případ > užití aplikace - založení objednávky, vyskladnění zboží, apod. Tento > UC má typicky nějaký začátek a řadu alternativních toků, které mohou > znamenat i výce způsobů jak ukončit jeho běh (dokončím vše, opustím to přes > cancel, opustím ho přes menu, apod.) . Mezi UC se dá provádět navigace, > přesně vím, kdy který začíná a kdy končí. Mohu ho autorizovat, apod. > (Myslím, že ve springu by se tomuto mohlo říkat Web Flow) > > No a když to implementuji, tak k jednomu UC dělám typicky jeden Controler, > který ho obsluhuje. UC se může skládat z více stránek (View) - třeba > wizardy, apod. Úkolem Controleru je obsloužit veškeré vstupní požadavky z > view - validovat vstupy, konvertovat vstupy, na základě vstupů volat > příslušnou business logiku (Model). Následně buď volí View, kterým daná > data vyrenderuje,nebo získá další (wizzard) a nebo se na základě vrácených > dat z business logiky rozhoduje o přechodu na jiný UC (tedy i jiný > controler) - tomu říkám Aplikační flow. A to řeším tak, že ten Controler v > případě přechodu na jiný UC prostě jen vyšle kód toho nového UC a nějaký > centrální handler provede ten přechod. - Tomu se může říkat třeba > FrontController. Takže já rozlišuji Application Controller a > FrontController - viz patterny. > http://www.corej2eepatterns.com/Patterns2ndEd/ApplicationController.htm, > http://www.corej2eepatterns.com/Patterns2ndEd/FrontController.htm > > No a co se týče toho View - U mě View nesmí nikdy obsahovat logiku, jen > renderovat, proto taky nemám rád JSP, PHP a jiné podobné technologie, ale > člověk se musí uhlídat. Z pohledu funkčnosti se mi více líbí technologie > jako Freemarker, které nic jiného, než vypsání a formátování dat na výstup > neumožňují. A k tomu renderingu jak píšete - tak buď bych to řešil tak, že > controler volí jen logické označení view, které se má použít - tedy řeknu - > ShowFormXYZ a pak nějaký FrontControler, ViewHandler, Filter, nebo jak > chcete, na centralizované úrovni vybere podle technologie klienta konkrétní > realizaci view, třeba tak, že k ShowFormXYZ přidá technologii: > ShowFormXYZ_800x600.jsp to pouze v případě, že opravdu logika je stejná > pro všechny variace toho view. > V případě, kdy logika je jiná - například pro malé rozlišení by se šlo na > wizzard, kdežto pro velké rozlišení je vše v rámci jednoho formu - bych asi > už na frontControlleru rozstřelil podle klienta na různé implementace > obslužných AplikačníchControllerů. > > A pak je tu ještě jedna možnost, použít tzv TwoStep view: > http://martinfowler.com/eaaCatalog/twoStepView.html > > Controler vybere View, to view ale nerenderuje pro konkrétní technologii, > ale sestaví jakýsi metamodel-view - třeba popíše výslednou obrazovku pomocí > XML (XUL, XAML, XML-FO, jiné) a toto se pak teprve transformuje podle > technologie klienta do výstupu, takže třeba budete mít různé transformace > podle rozlišení obrazovky, apod. Takže pak to neřeší controler, ale jakýsi > renderovací procesor toho view. > > Podle mě je vždycky MVC také otázka granularity pohledu, můžeme se koukat > na MVC s pohledu AJAXu, z pohledu serveru, z pohledu konkrétní visuální > komponenty. Možností je spousta, takže se těžko odpovídá na podobné obecné > dotazy. Jako zajímavé mi připadne řešení MVVM > http://en.wikipedia.org/wiki/Model_View_ViewModel. > > S pozdravem > > Petr > > > Dne 27.7.2011 14:33, Zdenko Vrabel napsal(a): > > Mne neslo uplne o typovo rozne view-s. Toto uz myslim presahuje MVC. Pri > niecom takom, kedy uz clovek uvazuje o napriklad tej konzolovke a tak sa uz > budeme bavit v rovine backend | frontend (alebo to SEO). Mozno som uviedol > blby priklad ale zoberme si MVC v iOS (no flame). Svojho casu to bolo jasne > ako facka. Tie devices mali rovnake rozlisenie obrazovky. Zrazu prisli > tablety, obrazovka sa zmenila a designeri mali silne nutkanie tuto plochu > vyuzit. Funkcionalita sa nemeni, len sa meni rozlozenie ovladacich prvkov. A > teraz ci je dobre mat nejaky obecny system na to alebo to s kludom moze > riesit controller a netreba tam pridavat dalsiu zlozitost. Podla mojho > nazoru sa MVC situuje vo frontende kde by controller mal riesit 'kliklo sa > na nejaky button' . View by to fakt mal len a len zobrazovat. Ja osobne uz > JSP povazujem za nie idealne, lebo clovek tam moze dat nieco co tam > nepatri (a castokrat tam aj da). > > Mozete mi pls poslat link na vas clanok ohladom toho SOA? > > Och asi strasne spekulujem ale kazdopadne dakujem za kazdy postreh. > > Dakujem, > Zdenko > > 2011/7/27 Oto Buchta <ta...@buchtovi.cz> > >> Ono je to hodně složité. Při různých View (a myslím tím typově jiných) je >> podle mého klasický model MVC trošku zavádějící. >> To, co v takovém případě chceme, je mít obecný model, nad kterým postavíme >> obecnou business logiku. Potom máme nějaké View, tedy něco, pod čím rozumíme >> vlastní renderování. Business logika je pak bude ovládána NĚČÍM, co se podle >> mne dá nazvat Controller (minimálně ve Strutsech se tak opravdu jmenuje) >> přes obecné API, ale co už renderování není. Něco, co rozhoduje, co se má >> zobrazit příště. O tom, že je naprosto jiné ovládání aplikace pro Androida, >> Web či z tlustého klienta je více méně jasné, ale přestoi bychom spekulovat, >> že ono rozhodování, co bude dál, ale může být typicky stejné pro celou >> aplikaci a že controller je tedy obecný a stejný a že controllerem je ono >> generické API. Zásadní rozdíl ale nastává ve chvíli, kdy si řekneme, že >> jedním z View bude také příkazový řádek, že chceme aplikaci ovládat ze >> skriptu. Tím se z toho skriptu stává do jisté míry controller. A nemyslím, >> že bychom mohli tvrdit, že příkazový řádek pak má možnost pouze komunikovat >> s modelem, tedy že máme zcela nový controller se stejným modelem. Nikoli. >> Chceme komunikovat s onou Business logikou, volat její SLUŽBY. Taktéž si >> nemyslím, že je skript ve stejné situaci ovladače jako člověk, tedy že před >> ním stojí nějaké View, za ním je controller a pak model. >> >> Tím se dostáváme k dalšímu problému, tedy kde je MVC v SOA. Pak by každá >> služba byla MVC sama o sobě. Ale o tom jsem už kdysi psal na blogu. >> >> >> 2011/7/27 Zdenko Vrabel <vrabel.zde...@gmail.com> >> >>> Dakujem za odpovede. Presne nieco taketo som potreboval zistit. Mna >>> zaujimal nazor viacero ludi ako to vidia. Ja osobne nejdem sutazit :) >>> >>> Zdenko >>> >>> Dňa 27. júla 2011 10:25, Dusan Msk <msk.c...@gmail.com> napísal(-a): >>> >>> Tiez nadobudam ten pocit. Nevidim dovod, preco by view nemohol vybrat >>>> controller. Je to na jednom mieste, nemusi sa to patlat tonou xml >>>> konfigurakov filtrujucich cosi kdesi z kadesi. Je mozne, ze v urcitych >>>> pripadoch to tak moze byt vyhodne, ja osobne som si ale zatial >>>> vystacil v kode v ramci controlleru. >>>> >>>> >>>> -- >>>> Dusan >>>> >>>> 2011/7/27 <michal.niko...@elanor.cz>: >>>> > Obcas mi pripada, ze to je soutez "Jak co nejvice vyber konkretniho >>>> view >>>> > zasmodrchat" >>>> > >>>> > NkD >>>> > >>>> >> Od: Petr Prikryl <peter.prik...@gmail.com> >>>> >> Komu: konference@java.cz >>>> >> Datum: 27.07.2011 09:48 >>>> >> Předmět: Re: Otazka ohladom MVC >>>> >> Odeslal: konference-boun...@java.cz >>>> >> >>>> >> Dobry den, >>>> >> myslim si ze view by nemel vybirat controller, ale nejaky filtr na >>>> >> requestu a mam takovy pocit ze to v spring MVC dokonce takto je, ze >>>> jde >>>> >> podle urcitych pravidel urcit jaky filtr se aplikuje. >>>> >> Dale me v tom navadi to, ze se kontroluje accepted-content-type takze >>>> >> snad se i takovy princip castecne pouziva (ikdyz toto je jakoby na >>>> >> jinou vrstvu). >>>> >> >>>> >> PP >>>> >> >>>> >> On Wed 27 Jul 2011 09:40:30 AM CEST, Zdenko Vrabel wrote: >>>> >> > Dobry den, >>>> >> > >>>> >> > Moju otazku by som chcel smerovat skor k MVC patternu ako ku Jave >>>> >> > samotnej tak snad to nebude vadit. Ak sa nahodou tiez budem pytat >>>> >> > somarinu, tak ma ospravedlnte ale potreboval by som sa len proste v >>>> >> > niecom uistit alebo naopak aby mi niekto povedal ze je to somarina. >>>> >> > Totizto nedavno som premyslal nad MVC patternom (pre web). Totizto >>>> >> > zaujimalo by ma, ci je spravne/nespravne ak v kompetencii >>>> controllera >>>> > je >>>> >> > rozhodovat o tom aky view sa pouzije alebo naopak. Mal by >>>> controller >>>> >> > vobec nieco vediet o viewoch? Vysvetlim na priklade. V dnesnej dobe >>>> sa >>>> > >>>> >> > dostavaju do popredia rozne iPhony, Androidy, iPady a neviem co. K >>>> > tomu >>>> >> > sa zacina aj prisposobovat design niektorych webov. Ide o to, ze >>>> dajme >>>> > >>>> >> > tomu design pre iPad je nieco uplne ine ako design pre klasicky >>>> > browser >>>> >> > (z pohladu web designera). To ma privadza k tomu, ze je potrebne >>>> > riesit >>>> >> > aky view sa na zaklade User Agenta pouzije. Moja otazka je vlastne >>>> o >>>> >> > tom, ci je spravne mat v ramci MVC nejaky mechanizmus routingu a >>>> >> > Controller by do toho nemal zasahovat (v podstate len produkuje >>>> model) >>>> > >>>> >> > alebo naopak. Takyto mechanizmus znecistuje MVC/ zvysuje jeho >>>> > zlozitost >>>> >> > a toto by mal riesit prave controller. Alebo je to uplne jedno? >>>> Este >>>> >> > doplnim ze hovorim o MVC vseobecne nie o nejakom konkretnom ako >>>> Spring >>>> > MVC. >>>> >> > >>>> >> > Za odpovede vopred dakujem, >>>> >> > Zdenko Vrabel >>>> >> >>>> >> >>>> > >>>> > >>>> >>> >>> >> >> >> -- >> Oto 'tapik' Buchta, ta...@buchtovi.cz, http://tapikuv.blogspot.com >> > > > > -- > Petr > >
