Please don't get me wrong. ViewRenderer is a great piece of code and is
appreciated by all of us. It just needs to be sequenced properly inside the
code so that only those who use it have its overhead.
Regards,
On 6/3/07, Shekar C Reddy <[EMAIL PROTECTED]> wrote:
Yes, its a case of ad-hoc naming of scripts (templates) for various
reasons. However, your control-flow is ideal:
final private function _viewRenderer()
{
// viewRenderer param is FALSE by default
if ( $this->_getParam( 'viewRenderer' ) && !
Zend_Controller_Action_HelperBroker::hasHelper('viewRenderer'))
{
Zend_Controller_Action_HelperBroker::addHelper(new
Zend_Controller_Action_Helper_ViewRenderer());
}
}
> On another note - there's no reason for the ViewRenderer not to work
with Smarty unless
> you've completely broken away from Zend_View_Abstract or are using
ad-hoc naming for
> scripts.
On 6/3/07, Pádraic Brady <[EMAIL PROTECTED] > wrote:
>
> /**
> * Constructor
> *
> * Instantiate using [EMAIL PROTECTED] getInstance()}; front controller
is a
> singleton
> * object.
> *
> * Instantiates the plugin broker.
> *
> * @return void
> */
> private function __construct()
> {
> $this->_plugins = new Zend_Controller_Plugin_Broker();
> $this->_plugins->registerPlugin(new
> Zend_Controller_Plugin_ErrorHandler());
> if
> (!Zend_Controller_Action_HelperBroker::hasHelper('viewRenderer')) {
> Zend_Controller_Action_HelperBroker::addHelper(new
> Zend_Controller_Action_Helper_ViewRenderer());
> }
> }
>
>
> If some amount of lazy loading were added it would help prevent early
> instantiation of the object if not being used. At the moment it's being
> instantiated immediately when constructing the Zend_Controller_Front method
> which is far from ideal. Why not push the logic into a small private method
> and shift it across to dispatch() which is the last method (usually) called
> on the Front Controller? That way the parameter switch could prevent the
> object from ever being formed...
>
> On another note - there's no reason for the ViewRenderer not to work
> with Smarty unless you've completely broken away from Zend_View_Abstract or
> are using ad-hoc naming for scripts.
>
> Pádraic Brady
> http://blog.astrumfutura.com
> http://www.patternsforphp.com
>
>
> ----- Original Message ----
> From: Shekar C Reddy < [EMAIL PROTECTED]>
> To: ltaupiac <[EMAIL PROTECTED]>
> Cc: Zend Framework General < [email protected]>
> Sent: Sunday, June 3, 2007 11:35:28 AM
> Subject: Re: [fw-general] Turn ViewRenderer helper OFF by default
>
> Great idea! But on a busy site (or when the site is busy), do you
> consider invoking an additional method such as removeHelper or setParam as
> not an overhead? Consider Yahoo! Consider a worst-case scenario when the
> server is pounded aka AJAX, Denial-of-Service Attacks... Further, by the
> time we invoke removeHelper, if the ViewRenderer helper is already
> instantiated, it is an overhead, too.
>
> Well, my point is this: There are two sections of folks that use the
> framework - those that use Zend_View/ViewRenderer and its
> sub-components/helpers/etc and those that use third-party templating engines
> but not ViewRenderer/etc. Given this scenario, a feature such as
> ViewRenderer should be incorporated generically/transparently without
> impacting anyone but only those who wish to utilize Zend_View/etc. This
> approach adds to backwards-compatibility, elegantly. For instance, I don't
> use ViewRenderer and wonder why I should be concerned about turning off
> something that I don't use at all in the first place! It just doesn't make
> any sense to me - not to mention the logic looks unnatural - like stepping
> forward only to back off, inevitably. I'm young today and can step
> forward/back-off (without any outcome) as many times as I want but when I'm
> weak/old (server busy), I may not be energetic enough to do all that
> superfluous processing. On the other hand, if the ViewRenderer is applicable
> to everybody (eg: controller/router/dispatcher...), that would be a
> different situation.
>
> In any case, it's not too late to turn off the ViewRenderer at this
> stage.
>
> ;~)
>
>
>
>
> On 6/3/07, ltaupiac <[EMAIL PROTECTED] > wrote:
> >
> > If you want to avoid overhead, you should better use
> > - Zend_Controller_Action_HelperBroker::removeHelper('viewRenderer');
> > instead of
> > - setParam( 'noViewRenderer', true )
> >
> >
> > Shekar C Reddy a écrit :
> >
> > Hi All,
> >
> > For those who use third-party templating engines and don't wish to use
> > the ViewRenderer helper (and even Zend_View), its additional over-head
> > of invoking methods such as setParam( 'noViewRenderer', true ), the
> > auto-addition of the helper object itself to the helper broker stack, file
> > I/O, latency, its various internal initializations, etc. do not make
> > any sense - not to mention it would likely degrade performance! However, for
> > those who wish to use its functionality, they could always invoke setParam(
> > 'viewRenderer', true ). One line of code in the boot-strap would make its
> > entire processing over-head sense to those who wish to use it.
> >
> > IMO, features should be incorporated in a *generic *way and should
> > apply to only those who wish to use them rather than auto-enable them
> > (instantiate/register) by default *only to be disabled *by those who
> > don't need them - it tantamounts to superfluous processing. Its like
> > auto-enabling/registering objects such as Zend_Cache, Zend_Config,
> > Zend_Session, etc. in the registry and then expect the developers to disable
> > them if they don't wish to use them.
> >
> > Thoughts?
> >
> >
> >
> >
>
>
>
>
> ------------------------------
> Get the Yahoo! toolbar and be alerted to new email
>
<http://us.rd.yahoo.com/evt=48225/*http://new.toolbar.yahoo.com/toolbar/features/mail/index.php>wherever
> you're surfing.
>
