Presenter a ViewComponenta

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
jardajirava
Člen | 4
+
0
-

Ahoj,
procházel jsem si quickstart a snažil se pochopit celou filozofii Nette. Zatím jsem prošel jen onen quickstart a zdejší fórum, z toho však vznikl můj zájem a zároveň i dotaz.

Co mě překvapilo je instancování ViewComponenty (DataGrid) přímo v presenteru. Přijde mi to, jako úzké svázání Presenteru s View, které by se nemuselo vyskytovat.

Moje otázka tedy zní, zda je skutečně nutné takto vytvářet komponenty, nebo existuje jiný způsob, kdy Presenter zprostředkovává komunikaci s Modelem a předává jen samotná data, prezentace je potom jen na samotném View (templatech). Jakou komponentu potom zvolím pro prezentaci dat bude jen na samotném View a při požadavku na změnu nebudu muset měnit Presenter.

Díky a pěkný den,

Jarda Jirava, Microsoft MVP – Client Application, MCAD, MCPD

http://jirava.net/blog

nAS
Člen | 277
+
0
-

Já myslím, že problém je v tom, že Nette nerozlišuje zvlášť ViewComponenty. Samozřejmě není problém, aby komponenta pouze něco vykreslovala (to by se hodila do View), ale častější případ je, že dále zasahuje do vnitřního stavu aplikace (anketa počítá hlasy, komentáře jdou přidávat, …) a toto chování se do View nehodí. V Nette je i Presenter poděděný od komponenty, což jasně ukazuje, jak jsou zde myšleny komponenty.

IMHO je filosofie taková, že komponenta má vlastní život, dokáže reagovat na různé události a pouze jedna z jejích vlastností je, že se dokáže vykreslit. A toto chování se hodí právě do Presenteru.

David Grudl
Nette Core | 8218
+
0
-

Jestli to dobře chápu, tak by jsi chtěl komponentu (resp. control) vytvářet v šabloně?

jardajirava
Člen | 4
+
0
-

Přesně tak, více by se mi líbilo, kdyby Presenter nevěděl nic o tom, jakým způsobem/komponentou má dojít k zobrazení dat. Pouze by se měl postarato o to, aby došlo k získání dat z modelu a jejich předání do šablony.

Pěkný den

Jarda Jirava, Microsoft MVP – Client Application, MCAD, MCPD

http://jirava.net/blog

Jod
Člen | 701
+
0
-

To sa mi zdá ako hlúposť, nato sú v šablone helpery. Nemýliś si to s nimi, kedže frameworky ako RoR, CakePHP a asi aj ASP.NET MVC nedisponujú nič lepším ako je template helper :D . Taký Nette/Control by som skôr jedine porovnával s UserControl v ASP.NET, ktorý sa tiež spracúva v kóde System.Web.UI.Page.

Editoval Jod (17. 4. 2009 10:02)

jardajirava
Člen | 4
+
0
-

Ahoj, myslím si, že jsem si to nepomýlil. Určitě nechci srovnávat, neboť Nette neznám natolik, abych si to mohl dovolit – co vím o asp.net MVC, tak to co jsi vyslovil taktéž není pravda.

Moje otázka však zůstává, je dobře vnášet do Presenteru zobrazovací komponentu? Není to přílišné svázání Presenteru s tím, co se má zobrazit? Nebo to zkusím obráceně, je možné vytvořit komponentu, která bude jen přebírat data poslaná šabloně a nějakým způsobem vykreslovat?

Pěkný den

Jarda Jirava, Microsoft MVP – Client Application, MCAD, MCPD

http://jirava.net/blog

Jod
Člen | 701
+
0
-

No mňa MVC v ASP.NET už nezastihlo kým som sa vyprdol na winy :D , tak som len tipoval podľa toho čo som videl na nete.

Podľa mňa na to čo o čom hovoríš ti postačí nejaký helper, alebo subTemplate cez include v curlyBrackets :) .

Mne componenty a controly v presenteru úplne vyhovujú, neviem ako ostatným. Možno by sa dala spraviť taká fičurda do curlyBrackets, že by sa len nadefinovala metóda createComponent a potom by sa už len v template napájali dáta na control. Niečo ako {control grid|$dataSource} , hehe :D

Honza Marek
Člen | 1664
+
0
-

No tak co by to nešlo…

{? $komponenta = new MojeNeco($data) }
{? $komponenta->render() }

Pokud to není nutné, tak bych to spíš ale nedělal, protože metody render{View} v presenteru by měly být taky součástí view.

Jod
Člen | 701
+
0
-

Skôr:
{!$presenter->getComponent(‚grid‘)->setDataSource($data)->render()}

:D :D :D

..neni zlý nápad, hehe

..kukám, že na tom zdrojáku začínajú pribúdať veci čo sa aj oplatí čítať :)

Editoval Jod (17. 4. 2009 10:44)

R2D2
Člen | 22
+
0
-

jardajirava napsal(a):

Ahoj, myslím si, že jsem si to nepomýlil. Určitě nechci srovnávat, neboť Nette neznám natolik, abych si to mohl dovolit – co vím o asp.net MVC, tak to co jsi vyslovil taktéž není pravda.

Moje otázka však zůstává, je dobře vnášet do Presenteru zobrazovací komponentu? Není to přílišné svázání Presenteru s tím, co se má zobrazit? Nebo to zkusím obráceně, je možné vytvořit komponentu, která bude jen přebírat data poslaná šabloně a nějakým způsobem vykreslovat?

Pěkný den

Jarda Jirava, Microsoft MVP – Client Application, MCAD, MCPD

http://jirava.net/blog

V prezenteru vytvářením komponenty právě nutně neříkám co se má zobrazit. Presenter sám o sobě je komponenta, když v něm vytvořím novou, jen tu logiku štěpím na víc částí které spolu úplně nesouvisí a jsou samostatné, někdy prostě není vhodné aby všechna logika byla v jednom presenteru, ale poskládat ji – stránka je rozdělená do několika částí které se chovají samostatně a nemusí o sobě vědět.. tj potřebují nějakou inicializaci v presenteru, který o nich neví dost na to aby se o to postaral :)

Pokud chceš jen přebírat data a nějak je vykreslovat, tak k tomu ti stačí budť obyčejný include v šabloně, nebo viewHelper, případně v šabloně můžeš udělat úplně cokoliv, vytvořit jakýkoliv objekt, dát mu jakoukoliv podmnožinu dat dostupných šabloně, nechat ho udělat svoji magii :) Ale už to pak je opravdu jen zpracování view, nette control je víc, spravuje signály které se musí zpracovat mnohem dřív než dojde k vykreslování. Jednoduchej příklad budiž odeslanej formulář – jeho výsledek chci zpracovat dřív než začnu vykreslovat šablonu, jinak bych nevěděl co vykreslit, respektive jestli vůbec něco – většinou po úspěšném odeslání formuláře následuje redirect. Nad komponentou se prostě provádí akce, které nepatří do view. Je to možná trochu jinak pojaté než jinde, ale zatím nám to přišlo efektivní :)

David Grudl
Nette Core | 8218
+
0
-

Asi nejprve by asi mělo být řečeno, že Nette používá vlastní koncept, pro který jsem teprve těsně před vydáním hledal terminologii a nejbližší se mi zdálo Model-View-Presenter, přičemž ani označení Model-View-Controller se nebráním a to z toho důvodu, že řada programátorů dělí frameworky na ty s MVC a ty špatné. Pro člověka, který se ve věcech dobře vyznát, to však může být matoucí.

Tím chci říct, že na třídu Presenter lze pohlížet jako na hodně špatně napsaný controller, nebo na hodně dobře napsané něco jiného ;)

Nejlépe by se dal Presenter popsat tak, že modeluje logické uspořádání stránky, přičemž může mít metody s prefixem render, které logické uspořádání transformují pro potřeby šablony a tedy spadají do vrstvy view. Což platí nejen pro Presenter, ale pro každého potomka třídy Control.

jardajirava
Člen | 4
+
0
-

Ahoj, díky za vysvětlení. Snad tomu začínám rozumět a přiřazovat si to do „svého“ světa asp.net, kde se to velice blíží právě Page FrontControlleru a v mém prvním příspěvku zmíněný DataGrid je vlastně uživatelský prvek, kterému se již předají data a on ví, jak je má zobrazit.

V takovém případě mám pár nápadů, zkusím je realizovat a kdyžtak se s nimi podělit.

Pěkný den

Jarda Jirava, Microsoft MVP – Client Application, MCAD, MCPD

http://jirava.net/blog