Router MVC

[Verwijderd]

Hey Allemaal,

Ik ben aan het uitproberen een MVC framework te maken, dit om het wat beter te begrijpen.

Mijn opzet is nu als volgt.

request >> router class (kijkt of de url overeenkomt met een route) >> front-controller (spreekt de juiste controller aan die bij de route hoort) >> controller >> models & views >> display.

Nu is mijn vraag, mag ik per route meerdere controllers aanroepen, bijvoorbeeld een header controller of footer controller?

Groeten,
Tim

[Wasp]

Headers en Footers zijn juist perfecte voorbeelden van views.

Je kan bv. een PageController maken die naast de inhoud altijd de header- en footerview rendered.

[Janoz]

Als je het hebt over 'header controller' en 'footer controller' dan heb je imho het concept nog niet helemaal scherp. Controllers zijn bedoeld om functionaliteit te bieden. Een actie die een gebruiker wil doen komt bij een controler aan en de controler voert die actie uit. De controler zorgt er vervolgens voor dat het model wordt opgezocht en/of aangepast.

[Verwijderd]

Hey Janoz,

Dit is nu precies zoals ik het nu doe. Maar dat betekend dus dat het ophalen van bijvoobeeld de metadata (uit het model) in elke controller moet worden herhaald. Bijvoobeeld, Static Page, Of contact Form, ect ect.

[ThomasG]

Er zijn verschillende manieren voor. Je kunt gebruik maken van partial views om je header en footer te renderen, of je kunt een soort layout blauwdruk maken welke uiteindelijk om de controller/view heen gegoten wordt, zoals o.a. Zend Framework dat doet. Aangezien je het zelf wilt gaan maken, heb je hierin veel vrijheid.

[Janoz]

Verwijderd schreef op dinsdag 04 juni 2013 @ 12:36:
Hey Janoz,

Dit is nu precies zoals ik het nu doe. Maar dat betekend dus dat het ophalen van bijvoobeeld de metadata (uit het model) in elke controller moet worden herhaald. Bijvoobeeld, Static Page, Of contact Form, ect ect.

Wat zie jij eigenlijk als je model? Wat zie je als 'metadata'? Het model is eigenlijk de gegevens die je weer wilt geven. Een nieuwsbericht met reacties kan een model zijn. Of een gebruiker met zijn gegevens. Vervoglens heb je een view welke de gegevens uit het model gebruikt om daar een pagina van te maken. Headers, footers forms zijn dingen die in je view geregeld zijn. Alleen de gegevens die ingevuld zijn in het formulier staan in je model, maar daar hoeft het model helemaal niks van te weten.

[Verwijderd]

Hey Janoz,

Het gaat niet om die metadata, maar om rechtstreekse data.
Bijvoorbeeld de titels van de pagina (wat altijd hetzelfde is). Deze data komt via een Mapper naar het model, en dan naar een view.

Maar om het daar te krijgen roep ik dus eerst een mapper aan > model en dan via het registry naar de view.

Het gaat er dus om of een website view (dus de hele pagina) echt maar uit één controller mag bestaan.
Of mag ik ook een controller maken die bijvoobeeld alleen een blokje op de voorpagina renderd?

Als ik dat blokje dat terug laat komen op andere pagina's roep ik gewoon die controller weer op?

Groeten,
Tim

[Janoz]

Zeker wanener je meerdere functionaliteiten op dezelfde pagina aanbiedt is het niet vreemd om meerdere controlers te hebben. Ik blijf me echter afvragen waarom je een titel van je pagina uit het model gaat halen.

Ik vermoed dat je het hele concept precies verkeerdom in je hoofd hebt zitten. Ik krijg het gevoel alsof je vanuit de pagina redeneert. Bij MVC moet je juist vanuit je data en functionaliteit redeneren. De view is uiteindelijk het laagje wat er bovenop komt om het ook voor de gebruiker bruikbaar te maakt.

[Verwijderd]

Dat is precies wat ik dus bedoel. Vandaar mijn vraag ook zo.

Dus ik kan in de router opnemen als bijvoorbeeld de URL is: /home

Dat de controllers >
header_data (wat de titel uit de database haalt en keywords data ect).
header_navigatie
home
footer_data

worden aangeroepen in een bepaalde prioriteit?

Begrijp ik dat nu goed?

[ Voor 15% gewijzigd door Verwijderd op 04-06-2013 14:58 ]

[johnkeates]

Kijk anders hoe ZF1 z'n dispatchloop heeft gedaan: http://nethands.de/download/zenddispatch_en.pdf

Het is helemaal niet zo ingewikkeld, en aan die volgorde kan je prima opmaken hoe MVC 'werkt' voor webpagina's die de eindgebruiker uiteindelijk ziet.

De view is niks anders dan een stukje HTML met wat placeholders, waarbij je bijvoorbeeld een controller hebt die afhankelijk van de user input bepaalde data uit een model gebruikt om een view te renderen.
Die view zelf zit dus altijd aan het einde, het is slechts een eindproduct, want als je bijv. niet een HTML view wil renderen, maar JSON output, dan zou dat gewoon moeten kunnen door niet dat stukje HTML als view te renderen, maar een JSON output, zonder dat je daar voor je controller of model hoeft te veranderen.

[Verwijderd]

Beste John,

Dat snap ik ook. Views komen als laatste en zijn eigenlijk niet meer dan templates (kan ook xml zijn of json of iets totaal anders) de content kan volgens mij uit dezelfde models en controllers komen?

ALs ik naar de PDF kijk zie ik daar dus een while die uiteindelijk de controllers runt. (meerdere kunnen dus achter elkaar worden uitgevoerd.) Mag ik die conclusie trekken?

Mijn schema lijkt nu erg op de PDF dus ik gok dat ik op de goede weg zit, een leuke leercurve!

[Woy]

Het is IMHO een gek idee dat je een aparte Header controller hebt. Die kan immers bijvoorbeeld niet bepalen wat de title van de pagina is. Bij bijvoobeeld een Home controller zal deze controller ook de data voor de header op moeten leveren.

[Janoz]

Je hebt het over header_data en footer_data. Dat is allemaal view gerelateerd. Als je een view hebt met een nieuws item dan weet die view dat de titel van die view bestaat uit de titel property van het artikel model object, niet omdat je een headercontroller aanroept.

[Verwijderd]

Hey janoz,

Het zijn voorbeelden!
Er is in de website bijvoorbeeld data die op bijna elke pagina terug komt. Daar gaat het me om.
Mag die in een aparte controller, of moet die in home_controller?

Die PDF was in iedergeval help vol.

[ Voor 9% gewijzigd door Verwijderd op 04-06-2013 15:33 ]

[Mike2k]

Verwijderd schreef op dinsdag 04 juni 2013 @ 15:31:
Hey janoz,

offtopic:
daar is nou de quote knop voor

[kaesve]

het klinkt een beetje alsof je HMVC wil, in plaats van MVC. Een iets ander concept waarin je 'controllers' niet meer voor functionaliteit schrijft, maar voor modules van je applicatie/website. Bij klassiek MVC zou je denk ik in elke controller opnieuw de data ophalen, ook al doe je dat in elke controller op dezelfde manier. Eventueel kan je een standaard controller maken met de functionaliteit die al je controllers moeten bevatten en deze dan uitbreiden dmv inheritance.

[Verwijderd]

kaesve schreef op dinsdag 04 juni 2013 @ 15:38:
het klinkt een beetje alsof je HMVC wil, in plaats van MVC. Een iets ander concept waarin je 'controllers' niet meer voor functionaliteit schrijft, maar voor modules van je applicatie/website. Bij klassiek MVC zou je denk ik in elke controller opnieuw de data ophalen, ook al doe je dat in elke controller op dezelfde manier. Eventueel kan je een standaard controller maken met de functionaliteit die al je controllers moeten bevatten en deze dan uitbreiden dmv inheritance.

Dit is precies wat ik bedoel. Nog een vraag hier over: Wie roept nu de lagen van controllers aan.

Is het controller1 > controller2 > controller3
of router > controller 1
router > controller 2
router > controler 3 in een bepaalde prioriteit.

[eM.]

Verwijderd schreef op dinsdag 04 juni 2013 @ 15:31:
Hey janoz,

Het zijn voorbeelden!
Er is in de website bijvoorbeeld data die op bijna elke pagina terug komt. Daar gaat het me om.
Mag die in een aparte controller, of moet die in home_controller?

Die PDF was in iedergeval help vol.

Ja dat kan, maar noem het liever mainController of appController . Daar maak je dan een functie getMenu() of getSettings() of wat dan ook.
Vervolgens zorg je dat al je controllers de mainController extenden.

Is dat wat je bedoeld?

[Verwijderd]

We komen al een eind in de richting.
Nog een vraagje, wie bepaald welke output er gekozen wordt.

Stel we hebben een controller News_list.
Deze controller heeft twee uiteindelijk views (html / xml).

Mag de controller nu op basis van de parameters van de router bepalen welke view er geladen moet worden?

[sub0kelvin]

Verwijderd schreef op dinsdag 04 juni 2013 @ 18:15:
We komen al een eind in de richting.
Nog een vraagje, wie bepaald welke output er gekozen wordt.

Stel we hebben een controller News_list.
Deze controller heeft twee uiteindelijk views (html / xml).

Mag de controller nu op basis van de parameters van de router bepalen welke view er geladen moet worden?

In MVC heb je vaak geen controller 'news_list', maar een controller 'news' met daar in een action 'list'. Dus het is niet de controller die bepaalt welke view geladen wordt, het is de action die dat doet. En ja dat mag op basis van de parameters die je binnenkrijgt, of dat nu per GET/POST parameters gaat, of via Accept-header, of op basis van extensie, dat maakt verder niet uit.

Dus '/news/list.xml en '/news/list.html' roepen dan allebei controller_news.list() aan, welke de juiste data ophaalt en op basis van de parameters bepaalt dat /views/news/list.xml.template of /views/news/list.html.template gebruikt moeten worden.

[Saven]

in principe wel, want daar is de controller voor. die bepaalt wat er gebeurt bij een bepaalde actie

[Verwijderd]

Duidelijk, al mijn controllers hebben een index action (die standaard wordt aangeroepen).
Is het logischer om bijvoorbeeld een list action toe te voegen aan de news controller, of mag de list ook in de index action staan?

[ThomasG]

Ik raad je aan om even wat bestaande MVC frameworks, en vooral de voorbeelden die hiermee gemaakt zijn, te bekijken. Ik krijg je indruk dat je geen idee hebt wat je nou eigelijk aan het doen bent.

[Verwijderd]

Een header of footer is een textbook voorbeeld waarbij dingen als viewhelpers (Zend) of widgets (Yii) komen kijken ... de manier om toch meer logica in een view te verwerken zonder teveel af te wijken van het MVC model.

Daarnaast om antwoord op je vraag te geven of een IndexController ook een listAction mag hebben ... waarom niet ? dat bepaal je zelf, als jouw indexcontroller een list action nodig heeft om bijvoorbeeld een overzicht van blog items te genereren ... prima !

Op je andere vraag , of de controller mag bepalen welke view er geladen wordt ... natuurlijk, want de controller is het element binnen de MVC stack die (zoals de naam al aangeeft) controle uitoefend / logica bevat... het kan dus heel goed dat de PageController een pagina inlaadt van type 'newspage' en daarom de view page_news.html inlaad in plaats van de view page_content.html.

Je vragen gaan vooral over of dingen 'moeten' ... moeten is hier een beetje een vies woord, het zijn guidelines of best practices maar indien dingen net iets beter/makkelijker kunnen door de regels iets te buigen of te breken, is dit aan jou als developer.

[Xanland]

Verwijderd schreef op dinsdag 04 juni 2013 @ 20:59:
Duidelijk, al mijn controllers hebben een index action (die standaard wordt aangeroepen).
Is het logischer om bijvoorbeeld een list action toe te voegen aan de news controller, of mag de list ook in de index action staan?

Zoals hierboven ook een beetje is gezegd, is het tot de "of" correct.

Daarnaast raad ik je ook nog aan een soort van constructor aan te maken genoemd init (oid). Hierin kan je iets doen wat je meerdere keren moet gaan doen. De index action kan je dan bijvoorbeeld gebruiken als standaard wanneer er geen actie is gedefiniëerd.

Bij controllers en actie moet je denken aan iets algemeens wat je kan uitvoeren, het zijn daarom ook niets voor niets classes. Een voorbeeld (webwinkel) is bijvoorbeeld een ProductController. Daarin/-mee kan je acties uitvoeren als toevoegen, verwijderen of wijzigen. Modellen zijn dan uiteraard de laag tussen de database en je code, waar je per tabel (ala ASP.NET MVC4 Linq idee) een model kan hebben.

[steffex]

probeer het eerst eens van een hoger design niveau te snappen: SOLID is een prima design om toe te passen op je eigen mvc framework.

[_Moe_]

Anders moet je het Kohana framework eens bekijken. Dit is een HMVC framework.

[Verwijderd]

steffex schreef op donderdag 06 juni 2013 @ 23:35:
probeer het eerst eens van een hoger design niveau te snappen: SOLID is een prima design om toe te passen op je eigen mvc framework.

No offense, maar deze opmerking is zo algemeen dat het nauwelijks waarde toevoegd als antwoord op de vraag van de TS.

SOLID is inderdaad een goede manier van opzetten en werken maar beslaat nogal een hoop design-principles en patterns die voor alle OOP applicaties gelden.