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?
