Hoe deze router werkt
- Wat gebeurd er in deze code zodat de file erbij gepakt word?
Ik heb al het een en ander proberen op te zoeken betreft classes maar kom er niet goed wijs uit en hoop dat iemand mij aan de hand van onderstaande code mij kan helpen het te snappen :)
INDEX.PHP
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
include 'router.php';
$request = $_SERVER['REQUEST_URI'];
$router = new router($request);
$router->get('/','app/home');
$router->get('post','app/post');
$router->get('hello','app/hello');
?>
include 'router.php';
$request = $_SERVER['REQUEST_URI'];
$router = new router($request);
$router->get('/','app/home');
$router->get('post','app/post');
$router->get('hello','app/hello');
?>
ROUTER.PHP
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Aan de hand van de URL in $_SERVER['REQUEST_URI'] wordt de juiste waarde van het eerste argument (bijv. hello) gebruikt om app/hello.php te openen.
Het leuke in dit forum met de codeblokken is dat je ook op de functies kan klikken voor extra uitleg. Een goede editor zou dit ook kunnen. Ook met het echo'en van wat variabelen in je script valt dit eenvoudig te debuggen.
Gewijzigd op 17/07/2019 00:52:31 door - Ariën -
Classes zijn helemaal nieuw voor mij en wil graag de structuur ervan snappen.
Zo wil ik een error 404 kunnen routen maar dan moet ik wel het bovenstaande verhaal snappen :)
Kijk bijvoorbeeld eens naar dit:
https://www.phphulp.nl/php/tutorial/overig/oop-beginnershandleiding-php5/701/object-georinteerd-programmeren/1838/
En met file_exists kan je kijken of een aangeroepen bestand bestaat of niet bestaat.
Gewijzigd op 18/07/2019 14:09:25 door - Ariën -
Bijkomend voordeel van het gebruik van een autoloader is dat dure functies (file_exists()) en extra aanroepen zoals include, require et cetera overbodig worden.
Een 404 "route" je waarschijnlijk ook niet, maar dit zou je moeten "berekenen". Nu include je simpelweg $file.php. En dit levert je niet eens een foutmelding op als deze ontbreekt, dus in dat opzicht zou -op dit moment, met deze werkwijze- een require_once beter zijn misschien.
Je moet kunnen constateren dat een pagina ontbreekt, dus je moet een soort van lijst of middel hebben om te bepalen welke pagina's "bestaan". Staat deze niet op de lijst dan serveer je de 404-pagina, inclusief een 404 Page Not Found HTTP-header.
Echter op het moment dat je je gaat bezig houden met routing moet je meteen een aantal zaken tegelijkertijd regelen in je applicatie om dit alles soepel te laten verlopen. Dit gaat veel verder dan wat routing-functionaliteit alleen. Dit heeft ook te maken met de organisatie en naamgeving van classes en de flow van pagina-aanroepen door je applicatie. Ook moet je gaan nadenken hoe je pagina's afschermt voor publiek als je speciale rechten nodig hebt om deze op te vragen. En dit alles moet soepel geïntegreerd zijn tot één harmonisch geheel.
Gewijzigd op 18/07/2019 14:50:38 door Thomas van den Heuvel
Bekijk als voorbeeld eens die van Laravel:
https://laravel.com/docs/5.8/routing
Gewijzigd op 26/07/2019 13:34:33 door - Ariën -
- Ariën - op 26/07/2019 10:05:26:
Bekijk eens die van Laravel:
https://laravel.com/docs/5.8/routing
https://laravel.com/docs/5.8/routing
Mja, maar dat is documentatie waarin héél summier wordt uitgelegd wat het doet en welke opties je hebt. Daar wordt ook enkel uitgelegd wat het doet, maar niet waarom het zo is opgezet. En als je verder niet bekend bent met de intrinsieke werking en filosofie van Laraval zelf dan helpt je dat niet zoveel. Ook zit daar redelijk veel jargon in die verder op geen enkele manier wordt toegelicht. Deze wordt bekend verondersteld. Misschien is dat op dit moment een (of enkele) brug(gen) te ver.
Zou het niet beter zijn om te beginnen bij wat routing nu precies inhoudt, wat de (algemene) principes hiervan zijn, waarom het uberhaupt fijn is om over zulke functionaliteit te beschikken in je applicaties en in welke situaties je routing het beste kunt gebruiken (je hebt het namelijk lang niet altijd nodig)?
Vervolgens zul je uit moeten weiden hoe je dit handig aanpakt. Afhankelijk van de vrijheid die je wilt hebben in de naamgeving van je URLs zal de routingfunctionaliteit die hier op inhaakt complexer worden. Hier zitten dus ook allerlei afwegingen/tradeoffs in.
Maar het simpelweg doorspitten van een documentatie verschaft je geen inzicht over de beslissingen die onderweg zijn genomen, en waarom specifiek is besloten om die aanpak te volgen - het toont je enkel het eindresultaat, dit keer in het Laravel-dialect. In dat opzicht is dat niet echt leerzaam omdat dit geen inzicht geeft over wat nu eigenlijk belangrijk is bij routing. Het geeft je simpelweg een aanpak, die je verder inhoudelijk niet hoeft te doorgronden om deze te kunnen gebruiken.
Verder heb je op GitHub ongetwijfeld ook een hoop router-classes die je in eigen projecten kan inbouwen.
Gewijzigd op 26/07/2019 13:06:47 door - Ariën -
- Ariën - op 26/07/2019 13:05:16:
Persoonlijk vind ik zeer duidelijk.
Dit is compleet irrelevant. Het gaat niet om jou. Het zou moeten gaan over de beeldvorming van wat "routing" is. Concreet, hoe een webserver externe verzoeken vertaalt naar een interne afhandeling.
Het gaat ook niet om de smaak waarin je dit uiteindelijk implementeert of overneemt uit een framework. Het gaat erom dat je de principes snapt.
Dit resulteert in een lijst voor de afhandeling van routing-specifieke taken. Dit is puur functioneel. In welke vorm je dit dan vervolgens giet doet er niet toe, zolang dit maar alle taken dekt.
Wat is de exacte nut en de werking van een router is, daar zijn op internet ook een hoop dingen over te vinden. Wie weet heeft de topicstarter er vast wel wat aan.