Door
Mark Hogeveen
op 06-12-2013 15:46
gewijzigd op 06-12-2013 15:49
11.710 views
Hallo, misschien een erg simpele vraag.
Bij routing voor je website stuur je eigenlijk alle requests door naar 1 pagina. Meestal index.php.
Doe je dan dus ook de POST data daarnaartoe sturen? En hoe doe je die dan weer doorgeven aan de juiste controller?
En hoe doe je alle get variabelen verwerken? Doe je dan iets als $_GET[0], $_GET[1] etc?
Ik begrijp niet echt wat het voordeel is van een router. Je moet telkens de juiste controllers/models/vieuws includen, soms (volgens mij) onnodig een header gebruiken om een gebruiker door te sturen naar de juiste locatie.
Daarnaast lijkt me het controleren van GET variabelen moeilijker, alles doe je rewriten naar mooie URL's,
Dus dit: www.site.nl/help.php?action=view&item=10023 wordt dit: www.site.nl/help/view/10023
Aan de tweede url zou je niet meer kunnen zien of view een map is, of (de waarde van) een veriabale.
Niet dat dit voor buitenaf belangrijk is, of dat bezoekers hier iets mee moeten. Maar hierdoor lijkt het me verwarrend. Ook zou ik niet weten wat ik moet doen als een pagina direct wordt aangeroepen, dus niet door de router, maar rechtstreeks (zonder include, en dus zonder code die in de router eventueel erboven zou staan, voor het include statement)
Een error 404 geven is dan eigenlijk liegen, doorsturen naar de router en zo een omweg maken lijkt me ook raar.
Je begrijpt dat je bij het url rewritten aangeeft dat die view hier een action query waarde is? Dus dat dat helemaal niks uitmaakt?
Bij MVC moet je bepalen wat er gaat gebeuren met die route, welke controller die gaat gebruiken. Dat doet een router. Die kijkt dus alleen, welke controller moet ik nu aanroepen. Is er geen controller gevonden, dan geeft hij een 404. Dat is geen liegen, er wordt een pagina aangeroepen die niet bestaat. We hebben het nu niet meer over dat simpele index.php font controller bestandje, maar over de pagina die je aanroept.
Elk php bestand op de server wordt eigenlijk gezien als een pagina, als je dus /controllers/welcome.php hebt, dan wordt die bij de router aangeroepen, en wordt er bijvoorbeeld een view van gemaakt.
Als je nu rechtstreeks het adres intypt naar welcome.php, roep je die dus aan zonder door de router te gaan.
Bij sommige systemen zie je in de code dat er een error wordt gegeven als "Direct script acces not allowed"
Dit vind ik lelijk.
Nee, niet elk bestand wordt gezien als een pagina. Alleen de front controller is een pagina, die beslist wie wat mag afhandelen.
De WelcomeController handelt bijv. de url index.php/ af. De PostController::showAction handelt index.php/post/123/hello-world af.
Als je naar /controllers/welcome.php gaat bezoek je geen pagina, je bezoekt een bestand met daarin informatie hoe je de url index.php/ moet afhandelen.
Als je naar /controllers/welcome.php gaat, dan bezoek je als het goed is een php Class en krijg je dus geen output te zien. Vandaar dat dit dus vaak met een "Direct access not allowed" wordt geblokkeerd. Je hebt daar namelijk niks te zoeken.
Je moet het net even iets anders aanpakken. Als je nou enkel en alleen je index.php in je "public" directory zet, en alle overige pagina's in een "private" directory, dan kan niemand via de browser een pagina aanroepen. In je index.php pagina in de public map zet je dan:
<?php
require '/pad/naar/private/map/index.php';
?>
In de index.php in de private map ga je dan gewoon verder zoals je dat normaal ook zou doen, alleen staan nu dus alle bestanden in de private map. Het voordeel is dus dat mensen via de browser niet meer rechtstreeks een pagina kunnen aanroepen zoals jij hierboven aangaf. Daarnaast is het een stuk veiliger... omdat mensen niet meer via de browser rechtstreeks een bestand kunnen aanroepen.
>> @Ozzie, waarom een require naar een private index.php file?
Wat bedoel je precies met je vraag?
Die index.php in je private map is de bootstrap. Door alle bestanden in een private map te zetten kunnen ze niet rechtstreeks via de browser worden aangeroepen en dit vergroot de veiligheid. Maar ik weet niet of dit een antwoord op jouw vraag is, of dat je iets anders bedoelde?
