hi iedereen
ik wil over een tijdje mijn online software geheel opnieuw gaan maken met goede php scripting

ik heb in de afgelopen maanden best veel geleerd hier van een aantal van jullie

en veel van die dingen wil ik dan ook gaan toepassen in mijn script
onder andere meer gebruik maken van classes
enz enz

nu heb ik persoonlijk wel 1 denk ik simpele vraag
ik gebruik op een aantal paginas heel erg veel includes via if ($page =

soms wel 30 verschillende paginas

is dit goed zo of moet ik daar iets anders voor gaan gebruiken straks?

even een stukje van 1 pagina


elseif($page == 'aanwezig') {
include("beheer/aanwezig.php");
}

elseif($page == 'settings') {
include("beheer/settings.php");
}
elseif($page == 'talen') {
include("beheer/talen.php");
}
elseif($page == 'alerts') {
include("beheer/alerts.php");
}
elseif($page == 'producten') {
include("beheer/producten.php");
}
elseif($page == 'intake') {
include("beheer/intake.php");
}
elseif($page == 'stap2') {
include("beheer/prijzen.php");
}
elseif($page == 'stap3') {
include("beheer/intake.php");
}
elseif($page == 'stap4') {
include("beheer/overeenkomst.php");
}


heeft iemand hier een mooiere oplossing voor?

en andere tips hoor ik ook graag :)
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.
Alle URL's naar /index.php in de root leiden zodat deze als front controller elke denkbare pagina kan produceren.
Ward van der Put op 13/09/2019 12:55:59

Alle URL's naar /index.php in de root leiden zodat deze als front controller elke denkbare pagina kan produceren.

ja dat doen ze eigelijk all maar in de index heb ik heel veel includes naar andere paginas

maar die front controller ziet er al heel netjes en beter uit dan wat ik heb

ik zal ook ff wat info zoeken over die array hiervan
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.
Waarom niet gewoon met switch of nog eenvoudiger

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

Jan
Voor "kijken of het bestand bestaat" hebben we is_file().

Beetje link dit altijd. Zometeen index.php?page=../../file-die-niet-direct-aangeroepen-mag-worden ...
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.
Frank Nietbelangrijk op 13/09/2019 20:15:05

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



Reageren