scripting tips???!!!
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
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
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");
}
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 :)
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.
Gewijzigd op 13/09/2019 12:50:08 door - Ariën -
front controller elke denkbare pagina kan produceren.
Alle URL's naar /index.php in de root leiden zodat deze als 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
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.
Gewijzigd op 13/09/2019 18:19:41 door Thomas van den Heuvel
Code (php)
1
2
3
4
5
6
2
3
4
5
6
if ($fp = @fopen($page . '.php', 'r')) {
fclose($fp);
include $page . '.php';
}else{
echo '<h1>Fout: Pagina "<u>'. htmlspecialchars($show1pagina) .'</u>" werd niet gevonden</h1>';
}
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
Beetje link dit altijd. Zometeen index.php?page=../../file-die-niet-direct-aangeroepen-mag-worden ...
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.
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)
Toevoeging op 13/09/2019 20:30:19:
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 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)
Toevoeging op 13/09/2019 20:30:19:
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.
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader.md
Voorbeeldcode met een anonymous function (closure) en een class:
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader-examples.md
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)
Toevoeging op 13/09/2019 20:30:19:
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.
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)
Toevoeging op 13/09/2019 20:30:19:
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
Sylvester vader op 16/09/2019 10:07:37:
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
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
Not Invented Here (NIH) syndrome
Goed, het zal een boel nieuwe informatie zijn, dat besef ik. En ik weet niet wat je doel is. Is dat PHP als hobby of is het doel om een pro te worden? In dat laatste geval ga ik je nu veel succes wensen ;-)
In ieder geval is het rijtje dat ik neer gezet heb een belangrijk rijtje van tools welke de professionele developers allemaal kennen. Uiteraard hoef je niet overal helemaal in doorgewinterd te zijn (beter goed thuis in één ding dan half in twee) maar op een aantal dingen zou je minimaal eens flink de aandacht moeten vestigen. En het hoeft niet allemaal tegelijk he. Zo heeft het denk ik niet zo veel zin om naar een framework te kijken als je nog niets weet over (ik zeg het even populair) OOP.
Quote:
en daarnaast hou ik er nooit van om dingen te gebruiken van anderen ook al is het iets goeds
Dus je bakt je eigen brood nadat je je eigen graan gemalen hebt? Ik wil maar zeggen je kunt als modern mens niet of amper leven als je niets van een ander wil gebruiken. En zo is het ook in de informatica.
Gewijzigd op 16/09/2019 18:34:31 door Frank Nietbelangrijk
zit ook misschien wel tussen mijn oren maar in verleden heb ik heel vaak scripts gebruikt of zogenaamd goede dingen
en dan hebben ze altijd net niet de functies die je nodig heb of er zit toch nog ergens een beveiligings lek in enz enz
even als voorbeeld veel mensen gebruiken nu bv wordpress, als er iets is waar ik een hekel aan heb is het wordpress
zoizo omdat 99% van hack pogingen op mijn server gerelateerd zijn aan wordpress (altijd grappig om te zien aangezien ik dus geen wordpress gebruik)
en aangezien ik dus veel met boekhoudingen doe en persoons gegevens wil ik elk detail van mijn gehele script dus ook weten
zoizo op delen die ik belangrijk vind
zodat als er iets fout gaat ik alleen myzelf de schuld kan geven en niet een 3de partij tool of script
het klopt dat je een wiel niet 2 keer moet uitvinden
maar als iemand een wiel heeft gemaakt die niet perfect rond is dan maak ik toch liever zelf een wiel
kijk mijn script is een site, waar bovenop allemaal dynamische sites staan, gelinkt naar begin domain
deze worden via het script zelf gesplitst naar de bijbehoorende gegevens enz enz
en mijn systeem draaien dus ff simpel gezegd 10 sites en bedrijven dwars door elkaar heen.
multi styling per klant en ben zelfs bezig met multi language
100% zelf gescript allemaal het enige dat ik niet zelf heb gedaan is het basis login/registratie script omdat ik dat 10 jaar geleden niet helemaal snapte mbt sessions enz
als ik iets schrijf wil ik dat ik zelf exact weet waar iets staat en niet eerst een manual van een ander script of server tool moet gaan uitpluizen als er bv een fout is die daar ergens inzit
en ik bv niet kan gaan zitten wachten op een update
als iets stuk is of een bug heeft moet het NU!!! gefixt worden en niet over 6 maanden
daarom gebruik ik dus niks van andere
Gewijzigd op 17/09/2019 10:30:56 door - Ariën -
Tegelijkertijd nodigt het niet echt uit om te reageren op een topic waar de houding een beetje "ga ik toch allemaal niet gebruiken" is. Als je om advies vraagt zou je op zijn minst de voorstellen kunnen verkennen of zelfs uit kunnen proberen in een eenvoudige proof-of-concept. Maar om nu op voorhand dingen af te wijzen wanneer je ze niet direct kunt overzien... Niemand heeft ooit geclaimd dat deze materie eenvoudig is, dus misschien is het gewoon een kwestie van wat meer moeite doen. En als dat niet jouw interessegebied / cup-of-tea is, ook prima, maar wees dan eerlijk naar jezelf (en ons) toe en besteed het lekker uit en zet ons niet voor niets aan het werk met vragen als je toch niet van plan bent iets met de antwoorden te doen.
Hoe dan ook helpt het wanneer je een nette werkhouding hebt en zorg besteedt aan de dingen die je doet. Dit wordt meestal ook gereflecteerd in de communicatie met anderen. Doorgaans besteden mensen die reageren aandacht aan het opstellen van antwoorden in lopende zinnen met een begin en een einde, dus dan is het wel zo netjes om dat ook te doen.
Dit is een forum, geen chatbox.
Het hoeft natuurlijk niet super strak allemaal, dat moet iedereen zelf maar uitmaken, maar het (overvloedige) gebruik van uitroeptekens en het verder vrijwel ontbreken van leestekens in reacties zou de indruk kunnen wekken van een zekere laksheid of gewoon een totale desinteresse.
Gewijzigd op 17/09/2019 17:53:17 door Thomas van den Heuvel