On another note, templating engines already come with a *huge *processing
overhead and the ViewRenderer's default overhead only makes it worse for
those that do not use ViewRenderer. The framework is based on the concept of
being light-weight with a tiny-footprint and lets stick to that concept.
On 6/3/07, Shekar C Reddy <[EMAIL PROTECTED]> wrote:
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?
>
>
>
>
