gebruik van ob_start
Ik ben al een tijdje niet zeker van de manier waarop ik een bepaald deel programmer.
Het zit zo.
Ik ben bezig zelf een soort cms/template systeempje te maken om natuurlijk van te leren en later misschien zelf in te zette voor mensen die vragen of ik een website voor ze in elkaar kan knutselen.
Ik heb in mijn mappen structuur een map met daarin .tpl bestanden.
Dit zijn dus mijn bestanden waar alle html in staat.
Nu zet ik daar ook stukjes php code in om variabelen te plaatsen op de plekken waar data moet komen in ik uit de database ophaal.
Ik gebruik daarvoor momenteel ob_start.
Ik haal eerst de data op uit de database en daarna start ik ob_start en require ik het template bestand.
Hierdoor kan ik alle variabelen die ik uit de database heb gehaald direct aan spreken.
Mijn vraag hier is:
Kan dit niet beter?
ik hoor soms dat ob_start niet echt de beste code is om mee te werken.
Mochten er nog vragen zijn hoor ik het wel.
groeten,
Dus ben erg nieuwschierig naar de reacties.
In het geval van Rick de Graaff, zie deze tutorial: http://www.phphulp.nl/php/tutorial/php-algemeen/header-already-sent/738/
Op dat moment heb ik mijn content ( output ) afgevangen in een $contents variabele. Het enige wat ik hoef te doen is een echo en mijn pagina is klaar.
Dus mijn vraag, is het gebruik van <ob>_ functies hier echt zo slecht?
Een schematische opzet:
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
<?php
$oTemplateParser = new TemplateParser();
$oTemplateParser->assign('var1', 'een waarde');
$oTemplateParser->assign('var2', 'nog een waarde');
// Doe allemaal dingen in PHP en assign nog meer variabelen
// Bijna het einde van je script
$oTemplateParser->display('template.tpl');
?>
$oTemplateParser = new TemplateParser();
$oTemplateParser->assign('var1', 'een waarde');
$oTemplateParser->assign('var2', 'nog een waarde');
// Doe allemaal dingen in PHP en assign nog meer variabelen
// Bijna het einde van je script
$oTemplateParser->display('template.tpl');
?>
Met de assign functie koppel je waarden aan variabelen binnen het TemplateParser object. Met de display functie pak je vervolgen een template en trek je benodigde variabelen uit je TemplateParser object.
Zoek ook eens op internet naar wat tutorials over het bouwen van een template parser, of kijk naar hoe anderen het gedaan hebben. Succes in ieder geval.
Vraag mij dan weer af of je een require kan opslaan in een variabel en dat alle variabelen die in het tpl bestand staan dan ook verwerkt zijn?
Ik heb wel een paar ideeen gekregen nu.
Ga er meteen mee aan de gang
Toevoeging op 19/01/2012 19:11:51:
Joren de Wit op 19/01/2012 19:10:04:
In de situatie die je in de post hiervoor beschrijft, zou het gebruik van output buffering misschien wel van pas komen. Ik kan me alleen geen helder beeld schetsen van hoe je het nu voor ogen hebt. Wat wil je met de preprocessing van je output bereiken?
ik had niet echt een manier waarop ik de variabelen die ik had in het document kon krijgen en zocht naar een manier waarop dat wel kon.
Ik denk alleen dat je mij die inmiddels gegeven hebt.
Ik ga daar eens naar kijken.
Dus de views die ik inlaadt in de controllers worden sowieso allemaal dynamisch ingeladen. Dus alle views ( .tpl) bestanden kan ik nu in 1 bestand hanteren, wat m`n content.tpl is. Waarom zou ik dan nog een keer de logics en traces moeten langs gaan als ik de antwoorden al heb? Als ze al bestaan kan ik het net zo goed tijdelijk opslaan en vervolgens mijn header.tpl en footer.tpl inladen en diezelfde variabelen gebruiken.
Gewijzigd op 19/01/2012 19:18:22 door Pieter Jansen
edit: op deze manier heb ik alle data van de content beschikbaar in mijn header terwijl ik anders logischerwijs eerst de header zou ouputten, dan de content en dan de footer. Nu doe ik eerst de content, heb dan alle logica die ik nodig heb en doe daarna pas de header en footer.
Gewijzigd op 19/01/2012 19:23:14 door Pieter Jansen
Naar mijn mening zou je de PHP logica die je nodig hebt voor je content output, losstaand daarvan moeten uitvoeren. Immers, als je op het punt aangekomen bent waar je output aanmaakt, zou alle PHP logica al afgehandeld moeten zijn. Ik zou dan ook eerder kiezen voor deze volgorde: 1. Alle PHP logica uitvoeren, ook degene die je nodig hebt voor de content, 2. Header output, 3. Content output, 4. Footer output.
Stappen 2, 3, en 4 zou je ook samen kunnen vatten door de views van header, content en footer te combineren door het aanroepen van 1 overkoepelende view waarin de 3 views afzonderlijk aangeroepen worden.
Over het samenvoegen, dat ga ik niet doen denk ik, ik hou er juist van om daar een soort van onderscheiding in te hanteren, ook de content zelf bestaat uit meerdere template bestandjes, list_view, detail_view, page_view etcetera.
Bedankt voor de uitleg, toch eens een keertje van die ob_ functies af :)
Ik vraag me af waarom je eerst de content laad, en niet zou beginnen met de header?
Dat maakt ook het gebruik van ob_start() vrijwel overbodig.
Ik vraag me ook af of het mogelijk is om data uit te content 'terug te halen'.
Mogelijk zijn deze gegevens al geparsed.
Daarnaast moeten de gegevens die je in de header zou willen gebruiken wel beschikbaar zijn. En omdat je de content dynamisch hebt, bestaat de kans dat dat niet altijd zo zou kunnen zijn. Als je eerst de header zou laden, zou je die gegevens eerder kunnen gebruiken dan vice versa...
In mijn eigen situatie gebruik ik alleen de output buffer voor debugging en om uncatched-exceptions op te vangen.
Succes!