RE: [SMARTY-DEV] Is Smarty using PHP output buffering?

From: Date: Wed, 07 May 2003 13:15:46 +0000
Subject: RE: [SMARTY-DEV] Is Smarty using PHP output buffering?
References: 1  Groups: php.smarty.dev 
Request: Send a blank email to php-smarty-dev+get-1402@lists.php.net to get a copy of this message
Because I don't want to change all my display calls... Overriding for this is just a hack to circunvent the lack of a switch, IMHO devels Override Smarty methods when they want the method to behave in a particular way for his application. Using or not using OB is something that doesn't depend on the application. > -----Original Message----- > From: messju mohr [mailto:messju@lammfellpuschen.de] > Sent: Wednesday, May 07, 2003 10:01 AM > To: luis > Cc: 'boots'; 'Smarty Dev' > Subject: Re: [SMARTY-DEV] Is Smarty using PHP output buffering? > > > On Wed, May 07, 2003 at 09:05:03AM -0300, luis wrote: > > I see some of you disagree with enabling OB for display(). > For this an > > backwards-semantic-compatibility I think that the best option is to > > provide a switch to use or not use OB in display defalting > to no (what > > previous versions used). Would you agree with this switch. > > Something simple: $smarty->display_output_buffering = true; > > Monte? > > why not > > ob_start(); > $smarty->display()... > ob_end_flush(); > > ??? > > > or overload display(): > > class Smarty_Buffy { > function display($tpl_file, $cache_id = null, > $compile_id = null) { > ob_start(); > parent::display($tpl_file, $cache_id = null, > $compile_id = null); > ob_end_flush(); > } > } > > > > there's no need for explicit output-buffering in smarty IMHO. > > greetings > messju > > > > -----Original Message----- > > > From: boots [mailto:jayboots@yahoo.com] > > > Sent: Tuesday, May 06, 2003 6:57 PM > > > To: luis; 'Smarty Dev' > > > Cc: 'Smarty Dev' > > > Subject: RE: [SMARTY-DEV] Is Smarty using PHP output buffering? > > > > > > > > > Luis wrote: > > > > IMHO smarty should default to the most efficient option > > > > > > I see your point. I think the issue is that "the most > > > efficient option" is really something that only the > > > application designer / site manager can decide, and that only > > > with some patience and trial and error. I don't think there > > > is a magic setting that is the most efficient in all cases. > > > Therefore, a conservative approach is nice--default to the > > > fastest/best options that won't cause extra overhead on the > > > majority of systems. Most systems are probably employing > > > techniques that obviate the need for automatic OB. > > > > > > I like Tom's suggestion of providing more reference material > > > to those trying to optimize Smarty's performance. > > > > > > But you do have a good point: out-of-the-box, Smarty should > > > try to be as fast as possible--as long as it doesn't become a > > > resource hog to do it, that is. > > > > > > __________________________________ > > > Do you Yahoo!? > > > The New Yahoo! Search - Faster. Easier. Bingo. > > > http://search.yahoo.com > > > > > > -- > > > Smarty Development Mailing List (http://smarty.php.net/) > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > -- > > Smarty Development Mailing List (http://smarty.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php >

« previous php.smarty.dev (#1402) next »