ViewRender will work with Smarty just fine. You just have to tell it to
use an view object that utilizes smarty for rendering (think setView()).
Check this blog post:
http://naneau.nl/2007/05/31/using-naneau_view_smarty-with-rc1/
That being said, I must admit that I am torn over the issue of whether
it should be enabled by default. On one hand, I really do believe that
it's a great addition and has to potential of reducing code size with
quite a fair amount. On the other it does add compexity, and may be hard
to understand for those new to the framework.
I think there should be more focus on the conventions the framework
assumes in the manual. I have the idea that people are deviating from
them (which they are of course free to do), and get into problems with
things like viewRenderer, because by default it assumes conventional
layouts.
MF
Sebastian Poręba wrote:
2007/6/2, Shekar C Reddy <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>:
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?
I fully agree, all additional features should be disabled by default,
with possibility of turning on in one line of bootstrap. If somebody
knows feature, knows how it works, it is more likely that he will know
how to turn it on. We should care about backward compatibility.
1.0.0RC1 with ViewRenderer was a big step, but makes all previous
applications incorrect. Especially as it doesn't work with template
engines like Smarty.
--
Sebastian
--
Maurice Fonk
[EMAIL PROTECTED]
http://naneau.nl/
Scio me nihil scire
