[php] losse of eenmalige output?

[supersook]

Ik ben bezig geweest met een template parser en hij werkt nu ook nog! Terwijl ik daarmee aan het werk was stuitte ik op de volgende vraag: "Wat is beter: allemaal losse output (echo()) in het script, of aan het einde alles in 1 keer naar de browser sturen?"

Dus wat zijn eigenlijk de pro's en cons van beide methodes? Graag jullie mening.

[Verwijderd]

Ik snap je vraag niet. Je hebt een template. Die parse je aan het eind, neem ik aan. De geparste content echo je in 1 keer. Wat valt er nog meer te echowen?

edit:

oh misschien dat je tijdens het parsen al stukken wil echoen. Mwoah, lijkt me niet practisch. Neem aan dat je een klasse hebt gemaakt. Laat de gebruiker van de klasse lekker zelf bepalen wat ie met de content doet. Kun je het ook voor email e.d. gebruiken. Maak functies show() en getContent() ofzo, kun je dur alles mee.

Een voordeel van pas aan het eind echoen is uiteraard dat je tijdens je script gewoon je template-object kunt gebruiken maar ook nog fijn headers en cookies enzo kunt sturen omdat je pas aan het eind echoot.

[supersook]

Op zaterdag 18 mei 2002 11:05 schreef fladder het volgende:
Ik snap je vraag niet. Je hebt een template. Die parse je aan het eind, neem ik aan. De geparste content echo je in 1 keer. Wat valt er nog meer te echowen?

dit is meer een algemene vraag, heeft niet specifiek met templates te maken ofzo, dus wat zijn de pro's en cons van beide manieren, of zijn die er helemaal niet?

[Verwijderd]

Er is geen verschil op de manier zoals jij zegt. Je PHP script gaat pas data doorsturen als het script is afgelopen, de echo commando's schrijven naar een buffer, niet direct naar de browser afaik.

Met een flush() in je script kun je de complete buffer alvast doorsturen, zodat de data al wél naar de browser wordt verstuurd, in afwachting van de rest.

[Verwijderd]

met ongebufferde respons kun je bijvoorbeeld een voortgangsindicatie van een proces op de server weergeven.
ik heb dat wel eens gebruikt in een (niet web) applicatie die via http statusmeldingen verwerkte.
dat kan niet me gebufferde respons.

de laatste versies van php geven niet standaard ongebufferde repons, volgens mij was dat in eerdere versies wel zo.

[vinnux]

Wanneer je tussentijds flushed komt da pagina sneller op het scherm. Het betekent namelijk dat je tijdens het parse process al data stuurt die ook al ontvangen en verwerkt kan worden, inplaats van alles in één keer op het einde.
Dit is dus bij langre scripts sneller.

Echter moet je er wel rekening mee houden dat <table> tags binnen IE (en volgens mij de rest ook) alleen maar worden weergegeven als er een </table> tag gevonden is, beheorende bij die begintag.

Ook moet je niet te kleine stukjes flushen, omdat de browser meestal, zo niet altijd ook nog een eigen ontvangst en verwerkingsbuffer heeft. Deze is echter niet van supergrote omvang.

Wat ik zou doen is alles wat je parst in een variabele stoppen, of echoen en af en toe , wanneer je bijvoorbeels tables sluit de flush te gebruiken.

[djc]

Op zaterdag 18 mei 2002 12:09 schreef Cheatah het volgende:
Er is geen verschil op de manier zoals jij zegt. Je PHP script gaat pas data doorsturen als het script is afgelopen, de echo commando's schrijven naar een buffer, niet direct naar de browser afaik.

Met een flush() in je script kun je de complete buffer alvast doorsturen, zodat de data al wél naar de browser wordt verstuurd, in afwachting van de rest.

Dit hangt ook af van je php.ini settings. Daar kun je output buffering uit zetten, dan wordt alles meteen doorgestuurd.

[martinvw]

Op zaterdag 18 mei 2002 14:00 schreef Manuzhai het volgende:
Dit hangt ook af van je php.ini settings. Daar kun je output buffering uit zetten, dan wordt alles meteen doorgestuurd.

Is dit ook tijdens de runtime van je script aan te passen want mijn provider zal vast niet voor mij die instelling willen veranderen in zijn php.ini

offtopic:
VGOUW --> Ik zou de link in je onderschrift een beetje veranderen door er http:// voor te zetten nu verwijst hij naar: http://gathering.tweakers.net/www.java.sun.com