vraag over ob_start() en session_start()
Ik heb een vraagje op de functies ob_start() en session_start(). Ik heb begrepen dat deze aan het begin van een script moeten staan. Maar moeten ze echt als allereerste staan, of moeten ze voor er enige "html" output wordt gebruikt staan.
Dat wil zeggen: in heb een bestand index.php, daarin wil ik alleen " in zetten en dan algemeen.php starten met:
Gaat dat werken?
Dank voor een reactie,
J.
Gewijzigd op 06/02/2016 21:11:15 door J opla
Dank je voor je reactie. Ik had die ob_start ergens voor nodig omdat anders iets ergens niet werkte ... vaag hè ... maar het precieze hoe en waarom kan ik me niet meer herinneren. ... Waarschijnlijk om de output buffering aan te zetten:
"This function will turn output buffering on. While output buffering is active no output is sent from the script (other than headers), instead the output is stored in an internal buffer. "
Maar wel bedankt voor je snelle reactie hoor!
Gewijzigd op 06/02/2016 21:24:32 door j opla
Het gebruik van output buffering zou wel een bewuste keuze moeten zijn bijvoorbeeld voor een zekere flexibiliteit in je programma-code. Maar wanneer je dit dan gebruikt zul je een des te grotere discipline moeten hebben bij het programmeren zelf zodat je deze speelruimte niet misbruikt.
Je moet te allen tijde kunnen onderbouwen waarom je iets doet. Als je ob_start() overal maar voorramt als een soort van aanroep van een magische formule ben je verkeerd bezig.
Dank je voor je reactie. Even voor mijn begrip: kan het kwaad als het er voor staat?
J opla op 06/02/2016 20:56:24:
Ik heb begrepen dat deze aan het begin van een script moeten staan. Maar moeten ze echt als allereerste staan, of moeten ze voor er enige "html" output wordt gebruikt staan.
deze functies, maar ook bijvoorbeeld header() en set_cookie() moeten staan op een plek waar nog geen output naar de client is gestuurd.
Want als er een byte aan data naar de client /browser gestuurd wordt, dan moet dat vooraf gegaan worden door http-headers.
Zeg maar een stukje info om te vertellen wat er aan komt.
Bijvoorbeeld: he browser, hiet heb je zodadelijk 165kB aan data.Dat gaat binaire zooi zijn en je moet het zien als een plaatje (jpeg). En waarschijnlijk blijft dit plaatje de komende 48 uur onveranderd, dus als je hem dadelijk weer nodig hebt, gebruik dan deze maar weer".
Maar het kan ook om html data gaan, en info over cookies bevatten etc. etc.
Zou je nu na deze headers en de eerste data op regel 300 van je script nog ontdekken dat je ook niet iets wilde zeggen over een extra header tbv een redirect of zo, dan ben je te laat. De headers zijn al verstuurd en op basis van die info is de browser al bezig een pagina op te bouwen.
Maar zo lang je nog geen headers verstuurd hebt, kun je ook op regel 1000 nog session start ztten
Dank je, dat vermoedde ik al, maar ben blij met je bevestiging.
J opla op 06/02/2016 21:35:22:
@Thomas
Dank je voor je reactie. Even voor mijn begrip: kan het kwaad als het er voor staat?
Dank je voor je reactie. Even voor mijn begrip: kan het kwaad als het er voor staat?
Nee. Je gebruikt enkel meer geheugen op de webserver (voor een kort moment). Alle OUTPUT (statisch en variabel) wordt namelijk eerst gebufferd in het RAM van de server.
En in principe is dat niet nodig als je je script logisch opbouwt. De hoofdregel is dat je in je script begint met PHP waarin je variabelen gereedmaakt die je nodig hebt bij de output. In dit deel komt geen enkele output voor. Daaronder komt dan je "view" . Dit is bij een normale webpagina dus je HTML met daartussen marginale stukjes PHP die enkel als doel hebben om dynamische content te genereren.
Klein voorbeeld:
(eerste deel)
Code (php)
(tweede deel, de view)
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
<DOCTYPE!>
<html>
<head>
<meta charset="UTF-8">
<title>My form</title>
</head>
<body>
<div class="warning"><?php echo $error; ?></div>
<!-- formulier hier -->
</body>
</html>
<html>
<head>
<meta charset="UTF-8">
<title>My form</title>
</head>
<body>
<div class="warning"><?php echo $error; ?></div>
<!-- formulier hier -->
</body>
</html>
Het gebruik van output buffering zou echter geen carte blanche moeten zijn om al je code maar door elkaar te gooien.
"Kan het kwaad" is niet echt een handige vraag. Output buffering is een middel, geen doel. Je slikt toch ook geen paracetamol als je geen hoofdpijn hebt? Je gebruikt het als je het nodig hebt en vermijd het als je het niet nodig hebt. En je moet nogmaals kunnen onderbouwen waarom. En niet "anders valt mijn applicatie uit elkaar" :).
Als je applicatie simpelweg niet werkt als je ob_start() achterwege laat en je weet niet precies waarom dan is dit waarschijnlijk omdat je dingen op de verkeerde plaats hebt staan en niet omdat de architectuur van je applicatie deze flexibiliteit (naar aanleiding van een overwogen en verdedigbaar plan) nodig heeft.
Gewijzigd op 06/02/2016 23:34:24 door Thomas van den Heuvel
Dank voor je reactie. Het probleem zit hem - wat ik me van een paar jaar geleden kan herinneren - in een gastenboek en een contactformulier dat ik heb overgenomen van elders en in mijn pagina heb proberen te integreren. Het is dus een medicijn tegen hoofdpijn en niet omdat ik het zo leuk vond.