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.
