RE: [SMARTY-DEV] Is Smarty using PHP output buffering?
| From: | luis | 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
>