Autor Zpráva
Petr233
Profil *
Dobrý den,

snažím se trošku dostat do MVC architektury v PHP, zatím nepoužívám žádný framework, protože si to chci vše osahat "from scratch".

Řekl bych, že spousty věcí okolo MVC chápu, jen mi nejde do hlavy jedna drobnost. Jak se realizují "moduly" na stránce v MVC? Resp. ony moduly jako je login box v levém panelu, menu či anketa.

Zatím mám princip: Router -> Controller -> Model -> Controller -> View -> Klient
View mám rozděleny na layouty a šablony controllerů, které se do layoutů vkládají.

Jak tedy do této logiky začlenit ty malé "moduly" na stránce?

Děkuji za rady.
ShiraNai7
Profil
To bývá řešeno jako "komponenty" vkládané v rámci view. Ve výsledku je to taky akce controlleru. Detaily závisí na konkrétní implementaci.
Kcko
Profil
Petr233:
Mám to podobně jako ty. S tím rozdílem, že nad tím mám ještě jednu vrstvu (říkejme tomu FrontView...)

Takže potom, když v nějakém controlleru -> jeho view potřebuju vyvolat nějaký menší modul z jiného controlleru tak si zavolám v šabloně toho view něco jako $this->frontView->insertModule('nazev', $configProParametry);

Ale konkrétní implementaci si musíš vymyslet sám, pokud máš svoje vlastní MVC.
Joker
Profil
Kcko:
Takže potom, když v nějakém controlleru -> jeho view potřebuju vyvolat nějaký menší modul z jiného controlleru tak si zavolám v šabloně toho view
Není tohle odpovědnost controlleru?
Resp. chci vložit nějaký obsah, tak řeknu příslušnému controlleru a on mi vrátí view?
Kcko
Profil
Joker:
Pokud volas Controller A a jeho metodu např. test (/A/test), vykreslíš šablonu a dejme tomu, že na té stránce má být anketa z Controlleru B , test, jak ji tam chceš dosadit?
Petr233
Profil *
Takže pokud to chápu dobře, toto není nijak přesně dáno, jak by se mělo dělat?

Když onu zodpovědnost vytváření modulů nechám na šablonovacím systému, například v šabloně budu mít {LoginBox} a šablonovací systém pomocí nějakého lokátoru instancuje LoginBox třídu, která nebude dědit od Controller, ale třeba od Controller\Module a zavolá nějakou defaultní metodu, která vrátí po všem výstup, který šablonovací systém vloží do hlavní šablony.

Je tato myšlenka trošku správně?
Joker
Profil
Kcko:
Pokud volas Controller A a jeho metodu např. test (/A/test), vykreslíš šablonu a dejme tomu, že na té stránce má být anketa z Controlleru B , test, jak ji tam chceš dosadit?
Takhle, ono samozřejmě je víc přístupů a záleží jak ten systém vypadá.
Například v Microsoftím MVC si to může view zařídit úplně sama, prostě zavolá metodu .Net frameworku, která jí vyrenderuje zadanou akci zadaného controlleru.
Jinde by úlohu toho pomocného objektu mohl převzít controller, neboli view by řekla controlleru, že chce zavolat akci jiného controlleru a ten by to zařídil (asi by měl nějaký pomocný objekt, který by to uměl).
Kcko
Profil
Joker:
V podstatě je to jedno a to samé, a záleží čistě na programátorovi, jak se mu s tím bude pracovat a jak to vymyslí.
Petr233:
To dědění si vyreš jak potřebuješ, akorát si musíš i vyrešit parametry, možná zbytečné tam do toho míchat zástupné značky, které budou prezentovat controller a jeho config a vykreslení.

Já to třeba na nějakém svém webu mám, aby editor mohl přidat anketu přímo do těla článku nebo galerii, takže to vypadá pak takto {POLL:8:global} // vykresli anketu ID 8 s nastavenim zobrazit vsude

nicméně přijde mi to zbytečné. Přečti si to co psal Joker, první způsob trošku poupravený pro moje potřeby využívám já.
Petr233
Profil *
Osobně mi sedí metoda, že budu mít zástupné jména v šabloně. Je "prasárna", že Controller\Model bude krást model dospělému Controller?
Tzn. mám Controller Pages, který mi bude řešit zobrazování stránek. Nyní mám Controller\Model jménem PagesList, který vypíše do "levého bloku" seznam nejnovějších stránek. Přijde mi zbytečnost psát pro PagesList další extra model, který prakticky dělá to samé, co model Pages. Takže chci udělat něco, že PagesList bude mít vlastnost se jménem controlleru, na kterém bude "parazitovat" a injektor mu načte model právě toho controlleru, který je specifikovaný ve vlastnosti.
Petr233
Profil *
Omlouvám se, trošku jsem se přepsal, Controller\Model má být Controller\Module.
Joker
Profil
Petr233:
Je "prasárna", že Controller\Model bude krást model dospělému Controller?
To není prasárna (jestli jsem to teda správně pochopil), ba právě naopak to je správné fungování. Naopak prasárna by byla říct, že controller má „jeho“ model, se kterým je svázaný a který se nemá používat nikde jinde. Přesně tak MVC fungovat nemá.
Petr233
Profil *
Skvěle, děkuji všem za rady a názory, moc mi to pomohlo!
Tori
Profil
Joker:
To není prasárna (jestli jsem to teda správně pochopil), ba právě naopak to je správné fungování.
Aha, takže nemám trojice MVC tříd, které se starají o konkrétní skupiny akcí/dat (tzn. např. pro vyhledávání bude model i view i controller), ale jednotlivé třídy, jejichž zodpovědnosti se nemusí mezi M-V-C zcela překrývat (tzn. např. budu mít model pro práci se stromovou strukturou, který budou využívat různé kontrolery)? Chápu správně?
Joker
Profil
Tori:
No, přijde na to, z jaké strany se na to díváš.
Z hlediska konkrétního zpracování konkrétní akce samozřejmě trojice existuje: Pro ten konkrétní běh bude existovat příslušný model, view a controller.

Co jsem chtěl říct je, že z celkového pohledu objektového modelu aplikace to tak není. Když budu mít akce A, B, C, neznamená to, že budu mít 9 tříd, které budou A-model, A-view, A-controller, B-model, B-view, atd. A že pro akci A se musí vždycky použít A-view a nic jiného.
Podle mě je právě smysl MVC, že ty části jsou oddělené a můžu vzít stejný controller a vyměnit view, nebo mít 20 controllerů, které všechny využívají jeden model.
Nebo třeba pro jednu akci můžu mít několik modelů a mezi nimi vybírat podle nějakých podmínek.

Ovšem samozřejmě „disclaimer“: Můžu se mýlit :)
Tori
Profil
Joker:
Z hlediska konkrétního zpracování konkrétní akce samozřejmě trojice existuje: Pro ten konkrétní běh bude existovat příslušný model, view a controller.
Myslela jsem to spíš ve smyslu druhého odstavce, tedy jestli je rozdělení zodpovědností podle požadavku (=trojice), nebo podle funkčnosti/typu zobrazení/entity.

Vaše odpověď

Mohlo by se hodit

Odkud se sem odkazuje


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: