Xuefer wrote:
is there any chance that a buffer in output buffer will be supported?
Nope, as this can cause all sorts of evil things.
Regards,
--
Michael - mike(@)php.net http://dev.iworks.at/ext-http/http-functions.html.gz
--
PHP Internals - PHP Runtime Development Mailing List
To
Marcus Boerger wrote:
i never liked the output buffering code much becuase i find it too complex
and too much stuff there is interacting in a way one cannot understand
easily.
[...]
So yes a redisign wouldn't hurt. And if that means we could get rid of
strange side effects of stuff that is
Marcus Boerger wrote:
And if that means we could get rid of
strange side effects of stuff that is imo abusing the output buffering by
using a temporary output buffer i'd appreciate it.
I guess you mean var_dump() and friends?
I didn't touch anything beneath Zend/ though.
Regards,
--
Michael
is there any chance that a buffer in output buffer will be supported?
supposing u're implementing send the whole page in html to friends
function. using smarty as email template.
if (isset($_GET['send_html_to'])) {
ob_start('send_as_html');
}
function send_as_html($content)
{
$tpl = new
Hello Michael,
i never liked the output buffering code much becuase i find it too complex
and too much stuff there is interacting in a way one cannot understand
easily. If there is a simple solution at hand that solves some problem and
that thing disables selective features by just disallowing
Zeev Suraski wrote:
I misread the post, I thought we were talking about ob_end_clean().
Yes, ob_clean() may cause this problem to happen, but again, the right
approach would be having an 'applicative' output buffer on top of the
gzip output buffer. We can look into letting output handlers
Jasper Bryant-Greene wrote:
Michael Wallner wrote:
I'd like to suggest that we revisit the output control (output
buffering) code base.
On a semi-related note, I'd like to see the docs mention that print_r
and var_export (with the second parameter set to TRUE), and
debug_print_backtrace,
At 13:51 27/02/2006, Michael Wallner wrote:
Hi,
I'd like to suggest that we revisit the output control (output
buffering) code base.
The current implementation uses way too less commands to do too many different
operations, which almost always causes problems with output handlers that need
to
On 2/28/06, Zeev Suraski [EMAIL PROTECTED] wrote:
I'm also not sure about what you're saying with the gzip/zlib headers
missing - do you mean the footers?
Refering to http://bugs.php.net/bug.php?id=36514 I belive
- Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
I misread the post, I thought we were talking about
ob_end_clean(). Yes, ob_clean() may cause this problem to happen,
but again, the right approach would be having an 'applicative' output
buffer on top of the gzip output buffer. We can look into letting
output handlers denote that ob_clean()
I'd like to suggest that we revisit the output control
(output buffering) code base.
The current implementation uses way too less commands to do
too many different operations, which almost always causes
problems with output handlers that need to maintain a state
or context.
Short
Michael Wallner wrote:
I'd like to suggest that we revisit the output control (output
buffering) code base.
On a semi-related note, I'd like to see the docs mention that print_r
and var_export (with the second parameter set to TRUE), and
debug_print_backtrace, internally use the output
12 matches
Mail list logo
