Je kan de pagina's ook in een array plaatsen, en kijken of ze overeenkomen met je $_GET of vergelijkbare variabele.
Die stappen lijken mij meer onder een bepaalde pagina te vallen. Dus lijken die hier niet op hun plek, vermoed ik. En is het meer iets voor intake.php.
Een design pattern is vaak een (abstract) idee. Er zijn dan ook legio implementaties (en interpretaties) voor eenzelfde patroon. Deze implementaties voeren vaak ook verder dan het idee van het patroon. Zo moet je ook nadenken over de structuur van je applicatie, en in welke mate zaken van elkaar afhangen.
Bijvoorbeeld, je zou een 1:1 vertaling van het "applicatie-pad" naar code kunnen maken. Het webadres (bijvoorbeeld https://jouw.website/bedrijf/contact) zou rechtstreeks kunnen corresponderen met het (interne) "code-pad" naar de bijbehorende code (/intern/pad/bedrijf/contact.php). Dit zou een aantal dingen kunnen versimpelen, maar tegelijkertijd beperk je jezelf ook in de mogelijkheden voor vrije naamgeving van webadressen.
Je kunt niet, althans niet zomaar, beginnen te breien bij een front controller als er nog geen structuur zit of ideeen zijn voor de rest van je applicatie.
Zoals eerder aangegeven, in deze single point of entry komen een heleboel dingen samen die het verdere verloop sterk bepalen.
Je bent in wezen bezig met het handmatig verwerken van requests en het tot op zekere hoogte zelf bouwen van responses, dus daar komt ook wel enige kennis van het HTTP protocol bij kijken. Op het moment dat je hiermee aan de slag gaat moet je enige kennis hebben van hoe je dit in goede banen leidt.
Persoonlijk heb ik een schurfthekel aan het woord "scripten" en "scripting". Hier gaat wat mij betreft nog steeds een soort van onvolwassenheid vanuit.
if ($fp = @fopen($page . '.php', 'r')) {
fclose($fp);
include $page . '.php';
}else{
echo '<h1>Fout: Pagina "<u>'. htmlspecialchars($show1pagina) .'</u>" werd niet gevonden</h1>';
}
Kijk of het bestand bestaat indien ja include anders foutmelding
Inderdaad, kan beter een soort van whitelist hebben.
Daarnaast, vermijd diskoperaties, dat zijn dure operaties.
Je bent waarschijnlijk beter af met een autoloader aanpak. Dan hoef je ook nooit meer iets te includen maar wordt dit allemaal automatisch geladen op grond van consistente naamgeving.
Wanneer je toch van classes gebruik wil gaan maken lijkt het mij een heel goed idee om een autoloader te gebruiken. Dan hoef je geen enkele include te gebruiken voor de classes die je gebruikt. er zijn enkele gestandaardiseerde autoloaders: PSR-4 en PSR-0. Deze zijn zo te downloaden en te gebruiken. Bij voorkeur gebruik je Composer hiervoor. Kort stukje Nederlandse uitleg hier.
Paar andere interessante (zoek)termen die je veel nuttig leesvoer kunnen opleveren:
- PDO
- php OOP
- php namespaces
- php routers
- php MVC framework
- php template engine (zoals Twig en Blade)
- php framework (zoals Symfony, Laravel of CakePHP)
[size=xsmall]Toevoeging op 13/09/2019 20:30:19:[/size]
Eigenlijk wordt de autoloader gelijk mee geleverd wanneer je composer gebruikt. Je kunt dit ook gebruiken om je eigen classes te autoload-en. Zie hiervoor deze pagina.
Wanneer je toch van classes gebruik wil gaan maken lijkt het mij een heel goed idee om een autoloader te gebruiken. Dan hoef je geen enkele include te gebruiken voor de classes die je gebruikt. er zijn enkele gestandaardiseerde autoloaders: PSR-4 en PSR-0. Deze zijn zo te downloaden en te gebruiken. Bij voorkeur gebruik je Composer hiervoor. Kort stukje Nederlandse uitleg hier.
Paar andere interessante (zoek)termen die je veel nuttig leesvoer kunnen opleveren:
- PDO
- php OOP
- php namespaces
- php routers
- php MVC framework
- php template engine (zoals Twig en Blade)
- php framework (zoals Symfony, Laravel of CakePHP)
[size=xsmall]Toevoeging op 13/09/2019 20:30:19:[/size]
Eigenlijk wordt de autoloader gelijk mee geleverd wanneer je composer gebruikt. Je kunt dit ook gebruiken om je eigen classes te autoload-en. Zie hiervoor deze pagina.
lol dit gaat mij dus allemaal ff te ver :S
ik denk dat chinees leren makkelijker is
:)
en daarnaast hou ik er nooit van om dingen te gebruiken van anderen ook al is het iets goeds
het is altijd gemaakt door andere, en hacks worden meestal gemaakt voor iets dat veel mensen gebruiken
ik gebruik liever gewoon mijn eigen hard coding maar deze wil ik wel goed gaan schrijven dit keer