Door
Harry H Arends
op 11-07-2017 17:48
gewijzigd op 11-07-2017 19:56
3.214 views
Ik ben maar gestart om mijn scripts opnieuw op te bouwen i.p.v. urenlang regel voor regel an te passen.
Gelijk de gelegenheid om meer structuur aan te brengen.
Een van de problemen was een foutmelding dat een bestand niet bestaat.
Dat wilde ik ondervangen door altijd een default plaatje te toen als een bestand niet bestaat.
Echter onderstaande code laat het script stoppen zonder dat deze output genereerd.
<?php
$Row['competing_for_country'] = 'NED';
// Create Flag directory Path
$FlagPath = dirname(__FILE__)."/images/Flags/";
$CountryFlag = dirname(__FILE__)."/images/Flags/FEI.png"; //Default flag
// Check if the requested flag exists
if (!(@file_exists(dirname(__FILE__)."/image/Flags/.$Row['competing_for_country']"")) {
// And then create the complete path+file name
$CountryFlag = dirname(__FILE__)."/image/Flags/".$Row['competing_for_country']."png";
}
echo dirname(__FILE__) ;
echo $FlagPath ;
echo $CountryFlag ;
?>
Echter dit script genereerd geen output dus de vraag is, is deze constructie fout en zo ja waar??
Het vierde argument in je mysqli-aanroep is voor de database.
$dblink = new mysqli($MySqlHostname, $MySqlUsername, $MySqlPassword, $MySqlDatabase);
Maar dan heb je tot nu toe nog alleen de eerste stap gedaan, en dat is de connectie omzetten naar OO. De rest moet ook nog gebeuren.
Wat jij nu beschrijft vondt ik niet in de link, maar is in princype gelijk aan de oude methode.
Ik doe alles beetje bij beetje om het verband niet kwijt te raken
Dit is het eerste voorbeeld van de constructor van MySQLi:
<?php
$mysqli = new mysqli('localhost', 'my_user', 'my_password', 'my_db');
?>
Als je dat — met alle respect hoor — over het hoofd ziet, dan denk ik dat je er verstandig aan doet om hier te stoppen. Anders gebeurt er zoiets als met de eerste link in je portfolio, om maar wat te noemen.
Ben het eigenlijk wel met @Ward eens. Je kunt nu wel een OO-saus over je code heengooien, maar als je verder niet nadenkt over de architectuur dan zou je je af kunnen vragen wat hier de meerwaarde van is.
Sure, je code wordt misschien wat korter door OO-equivalenten, maar de algemene structuur hiervan zal waarschijnlijk in wezen nog steeds de denktrant van een procedurele applicatie volgen.
Als je met OO aan de slag gaat moet je misschien ook wat meer conceptueel aan de slag gaan. Bijvoorbeeld: hoe bouw ik een pagina in het algemeen op.
Waarschijnlijk is op dit moment elke webpagina of eenheid functionaliteit in jouw site een standalone script die een aantal standaard includes heeft. Dit volgt niet echt een OO-denkwijze. Het staat dan, wat mij betreft, ook ter discussie of je de code van dit soort scripts in een OO-dialect zou moeten schrijven. In het beste geval krijg je dan een mengelmoes van object georiënteerde en procedurele code door elkaar.
