Re: [SMARTY-DEV] Smarty outputting headers when using fetch()

This is quite possibly outside the scope of this discussion, but this is a problem beyond just Smarty. It's a general problem in PHP that headers cannot be buffered transparently the same way that ordinary output can be buffered transparently. Is there any reason that PHP must send headers immediately in every case? My instinct is no because I know how many layers of buffering there are between a PHP script and the client browser. We need a patch to PHP itself to provide: new functions ob_get_headers() and ob_flush_headers() and ob_clean_headers() extend ob_start() to void ob_start ( [string output_callback [, boolean buffer_headers=FALSE]]) or perhaps have integer flags bitwise-ORed for forward configurability. Thoughts? Monte Ohrt wrote:

How about this: if you call display() it works as is, if you call fetch(), it accumulates the headers in $this->_http_headers array. Not perfect, but I don't want to add any new API functions if we don't have to. I'm not sure what to do with multiple fetch() calls though, reset the array each time? Could be problamatic if _http_headers was ever used for other things. Monte On Fri, 2002-12-06 at 08:35, Ivo Jansch wrote:

Hi, when I use fetch(), I can render a template to a string. But Smarty outputs headers to the browser. I think that isn't 'clean'. If I use display, it's ok if it does it for me, but if I use fetch(), I want to have full control of what gets sent to the browser. This is especially important when Smarty is used as a component in an application, where there might be other things that influence the headers that should be sent. Therefor I propose that the fetch() function shouldn't do a direct header() call, but do $this->addHeader() or something like that. The display function should than read the headers and output them. If I'm using fetch() to fetch the template, I'm going to be responsible for the output to the browser, and I could use something like $smarty->getHeaders() to see what headers it suggests. Ofcourse, I could disable $cache_modified_check, but it's not that I don't want to check this, it's just that I want to be in control of what gets sent to the browser. Currently there are situations where this could lead to real problems. Suppose I have cache_modified_check set to true, and I have a postfilter that performs some last minute changes to what is sent to the browser. If the templates haven't changed, but the postfilter does something dynamic, then the 304 header is already sent, and the browser will not see my postfilter changes. Another proposal: Even better, but not backwardscompatible, would be if the 304 header wasn't sent at all by the fetch() function, but is instead returned as a status. In this case, fetch() could be implemented like this (pseudocode): function fetch(&$contents, $params, ...) { if (not modified) {

    $result = SMARTY_NOTMODIFIED;

} else if (error) {

    $result = SMARTY_ERROR;

} // fill $contents with the template output. $contents = parsetpl()etc.; return $result } These are actually 2 different proposals. What do you think? Greetings, Ivo -- Ivo Jansch <ivo@ibuildings.nl> ibuildings.nl BV - information technology http://www.ibuildings.nl

-- Ketan Gangatirkar ketan@ketan.org