On Wed, Mar 25, 2009 at 1:12 PM, Alex Howansky <a...@birdview.com> wrote:
>
>> A lot have been discussed, but anyway it is still difficult to decide. A
>> project is to be developed, and more persons will have to work at it. Those
>> persons will have some experience in ZF and probably also in Smarty. The
>> problem is: what are the advantages and disadvantages of using ZF Template
>> Engine vs. Smarty. How much of you use Smarty? Why do you prefer
>> Smart/Zend_View?
>
> I think the greatest advantage to using a non-PHP templating engine in your
> view layer is that you can force logical isolation between your designers
> and your programmers. This is especially important if you have untrusted or
> external designers providing input for your product. I.e., you do not want
> your designers to be able to do things like this in a view template:
>
> <?php
>
> unlink('/path/to/file');
>
> $db = new PDO('...');
> $db->query('drop table ... ');
>
> ?>
>
Yes, but how many Smarty setups end up allowing the {php} tag because
there's something that they can't do in Smarty or it is easier to do
directly in PHP? My guess is that this is pretty common and, when it's
enabled, you're back to needing to trust the external designers. If
you're going to have untrusted input, I'm not sure that the view
script or templating layer is the appropriate place to handle this
untrusted input (I mean the view script or templating layer *itself*;
not *within* the view script or templating layer where handling
untrusted input is, in fact, perfectly appropriate).
This brings up an interesting point. Perhaps there's interest in
allowing/disallowing specific functionality within ZF view scripts?
I'm not sure how feasible this is from a technical point-of-view, but
perhaps it's something worth proposing if someone has a need for this
ability. It's not something I need (I trust the person working in my
view scripts), but sounds like it may be of interest to some.
Thanks,
Bradley
--
Bradley Holt
bradley.h...@foundline.com
