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

On Wed, May 07, 2003 at 10:15:46AM -0300, luis wrote: > 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. maybe not. and using or not using ob doens't belong into smarty, either. it belongs into your php.ini/httpd.conf/.htaccess . > > -----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Ȇ¸_ïé÷‚‘`ž > > > > t > > > > > > > > > > > > > -- > > > Smarty Development Mailing List (http://smarty.php.net/) > > > To unsubscribe, visit: http://www.php.net/unsub.php > >