/**
* 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?
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the
tools to get online.
http://smallbusiness.yahoo.com/webhosting
