PHP pagina structuur
Ik heb altijd geleerd dat wanneer je met PHP werkt dat je dan de volgende structuur moet aanhouden:
1. Logica eerst, en dus PHP scripts draaien eerst.
2. Daarna komt HTML aan de beurt.
En juist hierover heb ik dan een vraag, want voor mijn website gebruik ik de volgende structuur:
Voor elk nieuw pagina heb ik dan:
1. Logica eerst, dus er draaien wat PHP scripts.
2. include header
3. content nieuw pagina
4. include footer
Mijn concrete vraag is dan; Ik wil de foutmeldingen die uit PHP scripts voorkomen in de content laten zien en niet voor de header weer te geven.
Wat raden jullie aan om dit aan te pakken?
Ik dacht nl zelf aan om alle foutmeldingen in een array te stoppen, PHP scripts afbreken voor de header.In het content-gebied PHP script weer openen en alle foutmeldingen uit de array eruit halen.
Alvast bedankt voor het meedenken.
Smarty kan weer goed cachen.....
Als je echt een goede structuur wilt maken, verdiep je dan in het MVC-pattern.
TL;DR verdiep je in OOP, try-catch en (het werken met) exceptions.
Wat voor foutmeldingen bedoel je? Zijn dit fouten van dingen die kunnen optreden, bijvoorbeeld een verplicht veld is niet of niet juist ingevuld in een formulier, of zijn dit fouten die niet mogen plaatsvinden, bijvoorbeeld het uitvoeren van een query retourneert false wat zou kunnen duiden op een programmeerfout bij het opstellen van de query.
Eerstgenoemde fouten zijn niet kritisch en zouden de normale afhandeling van uitvoering van code en opbouw van de webpagina niet moeten onderbreken, de code zou moeten voorzien in het netjes afhandelen hiervan en de gebruiker hierover terugkoppeling moeten geven waarom een bepaalde taak (nog) niet uitgevoerd kan worden zodat deze bijvoorbeeld zijn/haar formulierinvoer kan verbeteren of aanvullen.
Laatstgenoemde fouten zijn echter een soort van onvoorziene situaties waarbij het niet direct duidelijk is wat er aan de hand is. De "toestand" van de code kan op dat moment onstabiel geworden zijn en het kan zelfs ter discussie staan of de applicatie zich nog kan redden uit deze situatie.
In dit geval zou de applicatie eigenlijk preventief aan de noodrem moeten trekken omdat er geen garantie is dat er nog goede dingen gaan gebeuren. Afhankelijk van de omgeving waarin dit gebeurt zouden er verschillende dingen kunnen gebeuren:
- in een ontwikkelomgeving zou de foutmelding rauw op het scherm gedumpt kunnen worden waarna de applicatie meteen afbreekt; dit is ook meestal het signaal dat de ontwikkelaar toe is aan een nieuwe kop koffie :)
- op een test- of productie-omgeving werken doorgaans (potentiële) klanten of opdrachtgevers met je systeem, het dan tonen van allerlei nerdy techtalk vergroot het vertrouwen in de correcte werking van een applicatie waarschijnlijk niet; in dit geval is het beter om een standaard foutmeldingspagina te tonen; ondertussen zou de fout op de achtergrond gelogd moeten worden; als de gebruiker vaak op deze manier vastloopt in het uitvoeren van een taak dan hebben zij ook vaak de beschikking over een ticketsysteem om hier melding van te maken, maar de logging die je zelf gebruikt zou er ook voor moeten zorgen dat dit soort dingen snel opgepikt worden
De informatie die je toont en de wijze waarop hangt dus af van je doelgroep en de omgeving waarin de applicatie actief is.
Nu, voor het tweede soort foutmelding waarbij er dus iets gebeurt waarin niet werd voorzien (en mogelijk duidt op programmeerfouten) zijn bij uitstek (het gebruik van) exceptions geschikt. Indien er iets gebeurt wat niet helemaal in de haak is genereer je (of throw je, zoals dat heet) een nieuwe exception. Hiermee zeg je in feite "Hee, ik heb geen idee wat ik hier mee moet, kan iemand dit verder afhandelen?". Deze detectie zul je dus wel moeten programmeren. Vergelijk het met het gooien van een bal. Deze zal ook weer ergens (op)gevangen moeten worden. Dit doe je in feite met een try-catch blok.
In het "try" gedeelte probeer je code uit te voeren waarin mogelijk foutmeldingen gegenereerd worden door het throwen van exceptions omdat er onvoorziene dingen gebeurden. In het "catch" gedeelte kun je foutmeldingen opvangen voor een alternatieve afhandeling. Let wel op: niet-gevangen exceptions genereren altijd fatal errors die er dus alsnog voor kunnen zorgen dat er foutmeldingen op je productie-omgeving verschijnen tenzij je het melden+weergeven voor deze omgevingen correct hebt ingesteld.
Een heel ander aspect -die hier wel rechtstreeks mee van doen heeft- is dan de opbouw van pagina's. Bij complexere applicaties is de opbouw doorgaans niet meer zo lineair als "eerst logica, dan de header, content en footer" (in die volgorde) maar werk je met intialisatie van objecten, (front end) controllers en de hele santekraam, en het hele werken-met-exceptions zal hierin verweven zijn. Het is natuurlijk handig als je hele applicatie dezelfde inslag (object georiënteerd programmeren) heeft. Maar mogelijk ben je nog niet zover. Exceptions zijn dan nog steeds bruikbaar in een soort van hybride procedurele/OOP vorm maar op het moment dat je applicaties in elkaar gaat zetten middels OOP gaat de volgorde logica/header/content/footer snel overboord.