De PHPhulp kroeg
HMVC vraag
Ik vroeg met af of je in een HMVC omgeving een standaart hebt hoe je controllers aanroept.
Normaal gezien laadt je maar 1 controller alleen in hmvc kun je meerdere controllers laden, Maar wordt deze in de (bijvoorbeeld ) index controller geladen of in de view of model ?
Kwam er zelf niet helemaal uit zelfs met zoeken want daar lees ik meer over modules. ( dus bijv, twitter module, facebook, blog, rss ect. )
Gr wouter.
Bijv. je geeft een route op voor index.php/contact (of index.php?page=contact):
Code (php)
1
2
3
2
3
main_contact:
pattern: /contact
defaults: { _controller: MainBundle:Contact:index }
pattern: /contact
defaults: { _controller: MainBundle:Contact:index }
De controller:
Code (php)
De View:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Contact</title>
</head>
<body>
<h1>Contact</h1>
<!-- CONTACT INFO HERE -->
<div class="sidebar-frame">
{{ render(controller('MainBundle:Sidebar:index')) }}
</div>
</body>
</html>
<html>
<head>
<meta charset="utf-8">
<title>Contact</title>
</head>
<body>
<h1>Contact</h1>
<!-- CONTACT INFO HERE -->
<div class="sidebar-frame">
{{ render(controller('MainBundle:Sidebar:index')) }}
</div>
</body>
</html>
Zoals je in de view hierboven kunt lezen wordt er weer een nieuwe controller aangeroepen om de sidebar weer te geven.
Voorbeeldje komt van Symfony maar dat is geen HMVC framework. Het principe is echter gelijk, het enigste verschil is dat Symfony geen Models kent. In plaats van een Model aan te roepen vanuit de controller wordt de data gewoon in de controller zelf verzameld. De exacte notatie van bijvoorbeeld de routes zijn per framework wel verschillend.
Gewijzigd op 02/10/2014 19:52:04 door Frank Nietbelangrijk
Bedankt voor je antwoord.
In jouw voorbeeld gebruik je symfony en die gebruikt weer twig.
Nu gebruik ik alleen twig en heb ik geen toegang tot de render functie die symfony wel heeft.
Dit zou dus betekenen dat ik een twig extension moeten maken die de render functie nabootst.
Of in ieder geval een extension maken die een "controller/module" kan aanroepen en gebruik kan maken van alle functies die beschikbaar zijn.
Heb jij misschien een idee hoe ik dit het beste kan doen.
Met betrekking tot het aanroepen van de functie in van de "controller/module" ?
In Symfony is dit natuurlijk standaard aanwezig. Google is je vriend :-)
Feitelijk hoef je alleen te weten hoe je een custom functie kan toevoegen in Twig.
http://twig.sensiolabs.org/doc/advanced.html#functions
Had dat topic al doorgelezen en heb al wel een idee hoe ik het wil implementeren.
Zal denk ik nog wel problemen tegen komen maar ik zal er eens een begin aan maken morgen.
(Btw, als Symfony doet wat jij wilt bereiken, waarom zou je dan nog zelf gaan knutselen?)
Had al gekeken hoe symfony dat deed maar keek op de verkeerde plek.
Zal hier morgen/vanmiddag na kijken.
Heb nu nachtdienst dus kan niet veel doen jammer genoeg
Als je die extra controllers in een view onderbrengt die bij de contactpagina hoort, dan krijg je dus telkens dezelfde pagina als je de contactpagina aanroept. Ik dacht eigenlijk dat het idee was dat zo'n pagina dynamisch (aan de hand van configuratie) wordt opgebouwd. Bijv. website A en B hebben allebei een contactpagina, maar op website B wordt een routebeschrijving getoond en op website A niet. Als je het in de view implementeert staat alles vast lijkt mij.
Gewijzigd op 03/10/2014 01:10:56 door Ozzie PHP
Het zijn voornamelijk kleine elementen die je opnieuw kunt gebruiken op meerdere pagina's als dit nodig is.
Denk hier bijvoorbeeld aan een navigatie module die je in een master layout zet.
Of een fb like module die je in een pagina of blog view verwerkt.
Dit zijn maar voorbeelden natuurlijk.
En wat mij ook een voordeel lijkt is dat je een default style zou kunnen toepassen op de modules en eventueel kunt aanpassen.
Gewijzigd op 03/10/2014 04:33:32 door Wouter Van Marrum
Ozzie PHP op 03/10/2014 01:10:32:
@Frank:
Als je die extra controllers in een view onderbrengt die bij de contactpagina hoort, dan krijg je dus telkens dezelfde pagina als je de contactpagina aanroept. Ik dacht eigenlijk dat het idee was dat zo'n pagina dynamisch (aan de hand van configuratie) wordt opgebouwd. Bijv. website A en B hebben allebei een contactpagina, maar op website B wordt een routebeschrijving getoond en op website A niet. Als je het in de view implementeert staat alles vast lijkt mij.
Als je die extra controllers in een view onderbrengt die bij de contactpagina hoort, dan krijg je dus telkens dezelfde pagina als je de contactpagina aanroept. Ik dacht eigenlijk dat het idee was dat zo'n pagina dynamisch (aan de hand van configuratie) wordt opgebouwd. Bijv. website A en B hebben allebei een contactpagina, maar op website B wordt een routebeschrijving getoond en op website A niet. Als je het in de view implementeert staat alles vast lijkt mij.
Volgens mij is het idee om dubbele code te voorkomen.
Als we op alle pagina's dezelfde sidebar willen zien en we hebben vijf verschillende pagina's dan gaan we natuurlijk niet vijf keer dezelfde code herhalen. (logisch toch) Dat is naar mijn idee dé reden. Verder kan het juist zeer zeker wél dynamisch:
1. je hebt alle vrijheid in je controller(s).
2. in twig kun je heel simpel een if() - else() - endif gebruiken.
3. je kunt een foreach() e.d? in twig gebruiken
4. je zou zelfs nog een array met config waardes kunnen meegeven. (not done)
Dus ook het aanroepen van die controller kan in een if()
Zodra je op het punt staat twee keer hetzelfde te gaan doen, moet je gaan refactoren. Bijvoorbeeld naar een service.
In dat opzicht is de naam HMVC misleidend, want het is geen MVC. Refactoren betekent namelijk niet automatisch dat je die dubbelingen in code dan in twee controllers gaat uitsplitsen.
De hiërarchie bij HMVC ontstaat niet doordat je MVC-modules binnen MVC-modules gebruikt, zoals een social media buttons-module binnen een footer-module binnen een webpagina-module. Dán krijg je inderdaad iets dat je niet wilt: een controller die vanuit een bovenliggende view in de hiërarchie wordt aangesproken. Je regelt dat op een hoger niveau, in de configuratie en in services van een kernel.
Frank zegt we hebben URL www.mijnsite.nl/contact en die roept de ContactController aan. Die ContactController roept vervolgens een view aan, en in die view worden weer andere (bijv. 5 stuks) controllers aangeroepen. Oké, prima... want dan gaan we niet wederom 5x die view opnieuw maken, maar we roepen gewoon die controller aan, en die zorgt voor de view. Correct?
Maar wat nu als 1 van die 5 controllers een MapController is die een plattegrond toont. Stel nu ik heb 2 verschillende websites, waarbij ik alleen bij de eerste een plattegrond wil tonen. Bovendien wil ik bij de 2e website een andere (dan die 5) controller erbij plaatsen. Hoe los je dat dan op?
Website 1 en Website 2 hebben niet dezelfde backend. Misschien hebben ze wel overeenkomstige modules, maar daarvan wordt bijv. de view in de applicatie specifieke bestanden overschreven.
Overigens zijn we nu wel dit topic aan het kapen, niet?
Dat weet je niet... ze kunnen toch op hetzelfde platform draaien en gebruik maken van dezelfde library?
>> ... maar daarvan wordt bijv. de view in de applicatie specifieke bestanden overschreven.
Dan ga je dus per (main)controller controleren of er een applicatie-specifieke view aanwezig is?
>> Overigens zijn we nu wel dit topic aan het kapen, niet?
Vind ik niet... ik probeer duidelijk te krijgen wat het doel is van de HMVC opzet. Klopt de opzet zoals deze door Frank wordt beschreven, of is misschien een iets andere aanpak wel wenselijk/handiger...?
Beide websites hebben andere eisen, zoals je al beschreef. Dus kunnen ze niet beide op dezelfde applicatie runnen. Wat je in dit zorgt gevallen vaak hebt is een "standaard" die alle basis features bevat. Daar bovenop komt dan per website de maakwerk code. In dit geval zou een plattegrond onderdeel zijn van deze maatwerk code.
>> Dan ga je dus per (main)controller controleren of er een applicatie-specifieke view aanwezig is?
Nee, dit zit als het goed is al in je framework ingebouwd. In Symfony kan je bijv. een StandardAppBundle hebben die een template StandardAppBundle:Contact:index.html.twig heeft. In het geval van Website 1 moet deze worden uitgebreid met een plattegrond, dus overschrijven we die in de application directory door een bestand /app/Resources/views/StandardAppBndle/Contact/index.html.twig te maken. Deze voegt dan de plattegrond toe.
Ik weet nu voldoende hoe ik het wil gebruiken.
Kom hier misschien nog eens later op terug,