Diskuze: MVC v oblasti webu
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Tvůrce
Zobrazeno 28 zpráv z 28.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
To je správně. Controller je řídící prvek. Slouží jako prostředník mezi modelem a View, který přijme vstup uživatele a zpracuje ho. Tedy požádá na základě vstupu o data model a ty nějak zobrazí (view). Jen jsem nepochopil tu konečnou fázi. Myslíš vykreslení View?
to jsem chtěl slyšet , jinak ano,konečnou fází myslím vykreslení View (se "zpracovaným" Modelem)... to předpokládám že by se dělo také z objektu Controller...
Předpokládáš dobře Jinak jsem rád, že se tu řeší i MVC. Tohle je první dotaz na toto téma, co jsem na Islandsoftu viděl Přemýšlel jsem, že bych tu MVC architekturu nějak uvedl formou článku, ale raději to přenechám zkušenějším.
Kolem MVC je hodně zmatků a spousta rozdílných schémat. Centrem _mého_ MVC je Simple Factory, která podle typu dotazu volá Controller nebo Viewer. Mívám jich i několik desítek. Všechny komunikují s Modelem, ale nikdy mezi sebou.
Takže ty vlastně za řídící prvek používáš další samostatný
objekt... A Controller používáš jen na zpracování vstupů?
Jinak budu také jedině rád, když se zde budou řešit "pokročilejší"
techniky... Určitě se mám ještě dost "učit".
Když už se tu mluví o MVC, nedávno jsem vymyslel takový jednoduchý MVC framework pro Islandsoft, zatím jede na localhostu a je hotový asi z 80%, brzy půjde do nasazení.
Dbal jsem na maximální jednoduchost, všechny frameworky co jsem viděl měly desetitisíce řádek a přitom neuměly nic, co by se nedalo udělat jednoduchou třídou. Proto jsem se rozhodl využít vlastního řešení.
Dost jsem se na tom naučil (díky Kite a Drahoši za trpělivost při mých dotěrných dotazech) a určitě se o některé zkušenosti podělím, plánuji dokonce, že bych zjednodušenou verzi časem popsal v nějakém seriálu tutriálů.
Simple Factory není objekt, je to jen krátká funkce, která se v pohodě vejde do index.php. Jeden řádek - volání jednoho controlleru nebo vieweru.
Controllery dostávají vstupy v surovém stavu, musí si je ošetřit, předat Modelu, a vygenerovat přesměrování stránky. Viewery generují kompletní výstup, který se v indexu jen vypíše.
Pro každou změnu mám samostatný controller, pro každý typ zobrazení samostatný viewer. Společnou část kódu samozřejmě dědím.
Zajímavou komponentou je AJAX, protože modifikuje data i vrací výsledek. Je to tedy jakýsi hybrid rozdělený do dvou metod objektu. Jedna metoda data modifikuje, druhá je zobrazuje.
ještě jednou prosím o radu,
Nedaří se mi přijít na praktický způsob provedení Vieweru v praxi, tak
aby se dal jednoduše zobrazit "všechen" grafický výstup s daty z
Modelu...
Dobré "provedení" mvc mi přijde Kitovo, viz výše, ale tam už vůbec
nechápu jak funguje Viewer (konečné zobrazení html s daty z Medelu) pokud s
Controllerem vůbec nekomunikijí... (pár řešení mě jistě napadlo např.
Předávání viewerům data přes paramatr, nebo _seter ale přijde mi to dosti
nepraktické!)
Můžeš použít Heredoc - jednodušší řešení, šablona však musí být součástí PHP. K tomuto účelu využívám metodu __toString(), která je součástí každého vieweru.
Komplexní řešení s externí šablonou můžeš udělat přes XSLT. Data nemusíš dávat do XML, ale rovnou je naskládáš do DOMu. Je to trochu obtížnější, ale je to rychlé a robustní. Chystám na to článek.
Šablonovací systémy typu Smarty nedoporučuji. Je to líné a moc toho neumí.
Viewer žádná data z controlleru nepotřebuje, pouze parametry a přístup k Modelu. Controller produkuje pouze stavovou informaci, ale stránku nerenderuje.
AJAX je hybrid. Funkci controlleru v něm zastává konstruktor, funkci vieweru metoda __toString(). Komunikovat spolu mohou, ale nepotřebují, protože informaci si předají přes Model.
Předávání dat přes parametry je standardní postup, na kterém nevidím nic nepraktického.
Pro úplné začátečníky s AJAXem bude asi nejlepší
http://citron.blueboard.cz/…tecniky.html
Až to budeš umět, podívej se, jak to dělá jQuery a možná u něj zůstaneš.
U MVC jsem si zvykl dělat jen jeden Model (proto velké 'M'), ale více controllerů a viewerů (pro každou činnost jeden). Výhodou je minimum provedených includů a krátký provedený kód při každém běhu. Je to tedy i rychlé.
Já mám ve svém abstraktním kontroleru pole, do kterého si nacpu proměnné, které chci mít ve vieweru. Není pak nic jednoduššího, než zavolat PHP funkci extract, která ti proměnné výbalí Vyhneš se tak šablonovacímu systému a celý problém se značně zjednoduší.
Můj kód v kontroleru tedy může vypadat takto:
$model = new ModelNeceho();
$this->promenne['jmeno'] = $model->getJmeno();
A ve view:
Jméno je: <strong><?= $jmeno ?></strong>
Toto pole se před předáním vieweru rekurzivně zentituje, aby se výstup ošetřil.
To je právě výsledek zmatku kolem MVC. Data by měla být soustředěna v modelu. Potom k nim může přistupovat libovolný controller i viewer, nemusí tedy komunikovat mezi sebou. Controller pak má na starosti pouze modifikaci, viewer pouze prezentaci.
V ROR jsou ve view vidět dokonce instanční proměnné controlleru a je to velmi uznávaný framework.
Controller je prostředník mezi modelem a view, právě ten se tedy nabízí k předání i držení dat.
To je právě tím, že existuje několik rozdílných schémat MVC a všechna jsou "ta pravá". Mně vyhovuje tato verze:
http://www.zdrojak.cz/…tektury-mvc/
Podle ní controller není žádným prostředníkem. Všechna data i validační pravidla jsou v modelu a jsou přístupná pro viewer i controller.
Jak mohou být data v modelu, když ten neví nic o stránce, kterou zobrazuji? Model je souhrn nějaké logiky, která se týka určité entity a nic víc.
Dle tvé definice by model držel data, která se ho netýkají. Mějme 5 modelů, každý má něco jako metodu getSalary(). Když budu chtít spočítat průměrný plat těch pěti modelů, kam dám proměnnou s touto hodnotou? Nemohu ji dát ani do jednoho modelu. Budeš tvořit další model pro každou stránku? Ne, prostě ji vložím do controlleru, kam patří.
Má to tak i ASPčko, všechny velké fameworky to tak mají. Neříkám, že tvůj způsob je špatný, asi jsi to pojal úplně jinak, když říkáš, že máš více kontrollerů, ale řekl jsi, že jsem to já pochopil špatně. A to není pravda.
Model je jen jeden. Přijímá data od controlleru, stará se o jejich permanentní uložení a poskytuje je vieweru.
Pokud budu chtít od modelu průměrný plat pěti objektů, zeptám se modelu na průměrný plat pěti objektů. A může se ho zeptat přímo viewer.
Nemohu najít své vyjádření, že bys MVC pochopil špatně. Napsal jsem jen, že kolem MVC je zmatek, protože každý ho chápe jinak.
Mě se moc nelíbí, že bych ve vieweru řešil, kterého modelu se na co zeptám. To je imho práce controlleru, který dle vstupních parametrů získá data. View má nastoupit s přichystanými daty a starat se jen o to, jak co zobrazit. Tedy alespoň tak mi to dává smysl.
Ano, napsal jsi, že je kolem toho zmatek a že by data měla být v modelu. To chápu jako že to mám špatně
Zřejmě jsme narazili na různé programovací styly. Ty programuješ asi hlavně objektově, já relačně. V objektovém pojetí jeden model skutečně stačit nebude, v relačním si s jedním vystačíš.
Průměrný plat pěti objektů získáš jedním dotazem SQL nebo XPath. Proto mi nešlo do hlavy, proč tím chceš zatěžovat controller.
Fórum je určeno k výměně názorů. Každý z nás píše svůj názor, jak by to mělo být. To ještě ale neznamená, že by názor toho druhého byl špatně. Oba mohou být správně, každý pro jinou oblast použití nebo pokud jsou zasazeny do jiného kontextu.
Dočkáš se. Chci to napsat jako článek, ale ještě na něj nepřišla řada.
Pole je vlastně speciální případ objektu a zejména při tahání dat z DB dostaneš výsledek právě do pole. Proto se jeho použití přímo nabízí. Je však možné vracet plnohodnotný objekt.
Ovšem při použití funkce extract() je nutné dodržovat náležitou opatrnost a nikdy neexpandovat data od uživatele.
Pokud vím, tak extract mi jen dle klíče založí proměnné. Klíče si určuji já, ne uživatel, úplně tam nevidím problém.
Problém může nastat, pokud necháš expandovat $_GET nebo $_POST. Je to lákavé, ale nebezpečné.
Zobrazeno 28 zpráv z 28.