kan geen data uit db halen
dankje nu snap ik ook inderdaad een beetje waarom
maar stel nu een layout template in je index
bv
Code (php)
als enige in je index en de rest in je php met een check login ?
werkt toch een stuk makkelijker als er dan een fout is zie je toch ook waar meteen dan alles in je index uit te zoeken ?
Maar het gaat er ook om dat alles bij de index binnenkomt. Wat als je straks 30 subpagina's hebt voor contact, reviews, informatie etc....
Ga je dan die includes ook steeds per stuk toevoegen? Tijdrovend werk.
Als je bijvoorbeeld een (POST) formulier aan het verwerken bent dan redirect je na afloop idealiter meteen door naar een resultaatpagina, of terug naar de invoerpagina met foutmeldingen. Je blijft in dat geval dus ook nooit op de deelactie van een pagina waar gePOST wordt. Dit zorgt anders namelijk weer voor problemen wanneer iemand besluit de pagina op zo'n moment te verversen (er wordt gevraagd of de informatie opnieuw gesubmit dient te worden wat mogelijk kan resulteren in dubbelposts en dergelijke). Omdat je meteen na afloop wordt doorgestuurd is het dus ook niet nodig om zichtbare uitvoer te produceren, die deelactie zou enkel de verwerking van het formulier moeten regelen. In dat geval zou de pagina dus ook niets weer moeten geven. De acties van een deelpagina bepalen wat er moet gebeuren, dit ligt niet op voorhand vast.
Quote:
werkt toch een stuk makkelijker als er dan een fout is zie je toch ook waar meteen dan alles in je index uit te zoeken ?
Mocht er ergens in een include iets mislopen dan krijg je nog steeds een zeer duidelijke foutmelding over waar (in welk bestand en op welke regel) dit misloopt. Wat dat betreft zijn PHP-foutmeldingen altijd redelijk duidelijk. Wanneer je een index-kapstok gebruikt zul je dus geen foutmelding krijgen in de trant van "er ging iets mis in de index en zoek verder maar uit waar het misging" :).
Gewijzigd op 12/09/2019 17:13:55 door Thomas van den Heuvel
https://www.w3schools.com/php/func_error_debug_backtrace.asp
Als je echt een uitgebreide applicatie hebt, geeft dit een hele back-trace naar met de route naar je fout.
Je kan dit ook in Exceptions gebruiken: https://www.php.net/manual/en/exception.gettrace.php
Uiteraard zijn zulke trace-routes niet bedoeld voor je publiek, dus het is leuk op een testomgeving, waarbij je anders voor publiek een algemene foutmelding toont (Er is bij ons wat mis) waarna je dit ergens buiten je webroot logt ;-)
Pas nog zo iets geschreven...
Code (php)
1
2
2
$notifyQuery = mysql_query("SELECT * FROM notifications WHERE user='".$data['username']."' AND deleted != '1' ORDER BY ID DESC") or die(mysql_error());
$notifyNum = mysql_num_rows($notifyQuery);
$notifyNum = mysql_num_rows($notifyQuery);
mysqli_error
mysqli_num_rows
?
Voornamelijk een 'i' toevoegen, en de syntax nalopen die wel eens verschilt met vaak een extra connectie-parameter.
Gewijzigd op 12/09/2019 19:39:55 door - Ariën -
Een wrapper maakt het wel makkelijk, maar het blijft altijd een kosten/baten verhaal die bepaalt of het zinvol is. Tijdens een toekomstige overgang naar een nieuwere PHP-versie speelt er altijd wel wat meer dan enkel MySQLi-functies aanpassen. En mogelijk worden er in de toekomst ook andere functies aangepast. Ga je dan ook een wrapper bouwen voor de string-functies? :-P En dan heb ik het nog niet over de array-fucnties en zo kunnen we wel een poosje doorgaan ;-)
Voor een open-source pakket waarbij de gebruiker zelf mag kiezen op wat voor database die wil gaan draaien kan ik mij de noodzaak van zo'n wrapper wel voorstellen. Maar in andere gevallen vind ik het 'mwah!'
Ik ben wel een voorstander van het gebruik van het object-georiënteerde MySQLi. Je kan prima gebruik maken van exceptions en de bestaande interne MySQLi-class zelfs uitbreiden via extend met eigen functies of geclonde functies. Bijvoorbeeld centrale errorafhandeling ín je query. Maar ook dit kan je (als je zin hebt) als wrapper gebruiken.
Gewijzigd op 13/09/2019 00:53:07 door - Ariën -
- Ariën - op 13/09/2019 00:02:29:
Een dergelijke aanpassing van de MySQL-functies is tot nu toe maar een enkele keer gebeurd
Een ezel stoot zich in het algemeen... :)
- Ariën - op 13/09/2019 00:02:29:
Een wrapper maakt het wel makkelijk, maar het blijft altijd een kosten/baten verhaal die bepaalt of het zinvol is.
Natuurlijk, je moet zelf de afweging maken of dit voor jouw applicatie de moeite waard is, maar het is ook gewoon "defensief programmeren". Stel dat je om wat voor reden dan ook op een gegeven moment PDO wilt gaan gebruiken in plaats van MySQLi. Wellicht omdat je meer en andere database-koppelingen hebt en uniform wilt blijven werken. Als je dus in je code netjes, maar rechtstreeks, MySQLi gebruikte, dan zul je dit nog steeds moeten aanpassen. Als je al een eigen laag/koppeling had om deze eindjes aan elkaar te knopen, dan hoef je enkel de implementatie aan te passen, de rest van de code blijft ongewijzigd. Daarmee wordt de scope van zo'n wijziging ook een stuk kleiner en daarmee is je code een stuk flexibeler. Vergelijk het met een laptop met vervangbare onderdelen en een laptop "uit één stuk". Sure, de variant met vervangbare onderdelen is dan wellicht duurder, maar hier doe je dan waarschijnlijk ook langer mee.
Simpelweg de kaart spelen <ik heb hier een triviaal voorbeeld> dus <deze (ingrijpende?) wijziging is niet nodig> gaat niet altijd op... Je moet ook kijken wat het je oplevert, maar je zou op zijn minst de afweging moeten maken.
- Ariën - op 13/09/2019 00:02:29:
Tijdens een toekomstige overgang naar een nieuwere PHP-versie speelt er altijd wel wat meer dan enkel MySQLi-functies aanpassen. En mogelijk worden er in de toekomst ook andere functies aangepast. Ga je dan ook een wrapper bouwen voor de string-functies? :-P En dan heb ik het nog niet over de array-fucnties en zo kunnen we wel een poosje doorgaan ;-)
Ik maak mijzelf geen illusies en wil ook niet doen alsof we hier code voor de eeuwigheid schrijven, maar het lijkt mij wel verstandig om je opties open te houden en jezelf niet (althans niet op voorhand) vast te programmeren. Met een wrapper spreid je risico. Dit geeft je ook ruimte wanneer je na verloop van tijd tot een ander of groter inzicht komt om implementaties aan te passen en/of uit te breiden. Dat is met hard coding toch echt een stuk lastiger danwel vrijwel onmogelijk.
Op dat moment vormt je eigen code de grootste belemmering om dingen aan te passen en daarmee mogelijk te verbeteren, en dat is natuurlijk nooit de bedoeling.
Gewijzigd op 13/09/2019 17:35:02 door Thomas van den Heuvel