gebruik van ob_start

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Advanced Mendix Developer Order Management Systeme

Advanced Mendix Developer Order Management Systemen (NL) Den Haag HBO/WO IT Professional "Als Advanced Mendix Developer impact maken op de groeiende e-commerce markt? Je doet dit bij PostNL door met je DevOps team onze Mendix applicaties verder te ontwikkelen, waarbij je complexe logistieke business processen vertaalt naar applicaties die ons primaire proces ondersteunen". Wat ga je doen? PostNL wordt een postal tech company We nemen de ontwikkeling van onze IT applicaties in eigen hand door onze eigen software-ontwikkel-capability op te zetten. Als Advanced Mendix Developer ben je onderdeel van een multidisciplinair, agile werkend Business-IT-team. Samen met dit team bouw je onze logistieke IT-applicaties verder

Bekijk vacature »

Jeroen kolkman

jeroen kolkman

19/01/2012 18:41:30
Quote Anchor link
Hallo allemaal,

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,
 
PHP hulp

PHP hulp

16/10/2021 01:03:10
 

19/01/2012 18:46:20
Quote Anchor link
Daar ben ik ook wel benieuwd naar want vaak gebruik ik het ook omdat ik soms een header location in php gebruik.
Dus ben erg nieuwschierig naar de reacties.
 
Obelix Idefix

Obelix Idefix

19/01/2012 18:50:01
Quote Anchor link
Als je de pagina goed opbouwt (en juiste foutafhandeling hebt), heb je geen ob_start nodig.
 
Wouter J

Wouter J

19/01/2012 19:00:42
Quote Anchor link
Het gebruik van op_start() is verkeerd. In jou geval kan het volgens mij ook zonder gebruik van ob_start() en gewoon alleen een require.

In het geval van Rick de Graaff, zie deze tutorial: http://www.phphulp.nl/php/tutorial/php-algemeen/header-already-sent/738/
 
Pieter Jansen

Pieter Jansen

19/01/2012 19:04:43
Quote Anchor link
@Wouter, dank je voor de link naar de tutorial, nu heb ik alleen nog wel een andere vraag, wat als je de output preprocessed? Oftewel je gebruikt REGEX over je HTML heen, m.a.w. er is eigenlijk helemaal geen sprake van output, waarom zou je dan geen ob_start() kunnen gebruiken? Ik heb zelf namelijk ook een tpl engine gecode en daar kun je best veel mee, het enige is dus dat deze de ob_start(); gebruikt om alle content ( inc. variabelen ) te kunnen hanteren. Vervolgens vang ik het keurig op met ob_get_contents(); en sluit ik het af met een ob_end_clean();

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?
 
Joren de Wit

Joren de Wit

19/01/2012 19:08:02
Quote Anchor link
In het geval van een template engine moet je ervoor zorgen dat je de display() functie, waarmee je je template weergeeft (en dus de eventuele PHP code daarin uitvoert), zo laat mogelijk uitvoert. Je hebt in dat geval nooit ob_start() nodig om de output te bufferen...

Een schematische opzet:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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');
?>


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.
 
Jeroen kolkman

jeroen kolkman

19/01/2012 19:08:18
Quote Anchor link
@merijn zo gebruik ik het inderdaad ook.

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?
 
Joren de Wit

Joren de Wit

19/01/2012 19:10:04
Quote Anchor link
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?
 
Jeroen kolkman

jeroen kolkman

19/01/2012 19:10:35
Quote Anchor link
@joren thnks voor de kleine tutorial XD

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.
 
Joren de Wit

Joren de Wit

19/01/2012 19:14:56
Quote Anchor link
@Jeroen: mijn tweede post was nog gericht op de post van Merijn. Niet zozeer op die van jou ;-)
 
Pieter Jansen

Pieter Jansen

19/01/2012 19:15:51
Quote Anchor link
Nou kijk, ik zal het anders schetsen, de template engine doet er hier niet eens zo veel toe om 1 kritiek puntje, leg ik zo uit. Ik maak standaard gebruik van 3 .tpl bestanden, een header, een content en een footer. De eerst- en laatstgenoemde veranderen verder niet zo veel, maar ik hou er van om een soort van scheiding te hebben tussen in mijn html document. Het enige wat ik doe is de middenste ( de content ) aan te passen. Dit is waar de pagina-specifieke content opgehaald wordt, dat wordt keurig door de tpl engine gedaan, maar nu het volgende, soms wil ik berekeningen en variabelen uit de content terug halen naar mijn header.tpl bestand, op zich geen probleem, ik heb de ->assign() eerder gebruikt maar de variabelen zoals in de content.tpl bestaan al, dat ik zoiets heb van, als ik nu de content.tpl als eerste ga verwerken, kan ik de variabelen ( de controllers et cetera) allemaal gebruiken voor m`n header.tpl bestand.

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
 
Joren de Wit

Joren de Wit

19/01/2012 19:19:17
Quote Anchor link
Begrijp ik goed dat je variabelen terug gaat halen uit output die je al deels gegenereerd hebt? Ik weet niet of ik dat zou doen. Die variabelen heb je immers in een eerder stadium toegewezen aan je template parser, dus waarom zou je die proberen te reconstrueren uit je output? Of begijp ik je verkeerd?
 
Pieter Jansen

Pieter Jansen

19/01/2012 19:21:00
Quote Anchor link
Ja en nee, het gaat meer om de volgorde die ik nu hanteer. Ik handel eerst de content af ( die sla ik op in de OB) en dan begin ik met de echte output van de header, vervolgens de OB en daarna de footer. Zo heb ik alle logica welke ik in de content heb afgehandeld, ook beschikbaar in de header.

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
 
Joren de Wit

Joren de Wit

19/01/2012 23:25:43
Quote Anchor link
Oke, tot zover begrijp ik het. Maar dat zou dan betekenen dat je voor het genereren van de content output nog PHP logica nodig hebt. En de uitkomst van de PHP logica die je daar gebruikt, heb je dan tevens nodig in je header.

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.
 
Pieter Jansen

Pieter Jansen

19/01/2012 23:54:19
Quote Anchor link
Akkoord, ik denk dat ik het dan toch eens anders aan ga pakken. Ik ben net begonnen met een nieuwe boilerplate MVC, dan zal ik het daar anders aan gaan pakken. Misschien ook eens een nieuwe template engine schrijven of gewoon een bestaande als Smarty gebruiken.

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 :)
 
- Jim  -

- Jim -

20/01/2012 00:10:42
Quote Anchor link
Even snel doorgelezen...

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!
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.