From: "Kelly Hallman" <[EMAIL PROTECTED]>

> Sure, they could. However, take a look at all the newbie questions on this
> list. Maybe you've got time for all that hand holding.. but Smarty is a
> lot closer to HTML, which many of them already know.

{$variable} is no more closer to HTML than <?=$variable?>. Either way you
still have to teach them the templating engine langauge. That language can
either be Smarty or a specific subset of PHP functions/methods that serves
as your templating engine (like how Justin had to write the "cycle()"
function). If you can teach them how a {section} works, then you can teach
them how a foreach() works or write a section() function that works just the
same.

> If you call inline code and variables a templating engine, I
> can see why you don't get it. PHP can serve a templating purpose, but it
> doesn't greatly facilitate that out of the box. It's not a strategy.

Mixing PHP and HTML is not this big, bad, evil thing that should be avoided
at all cost like many people make it out to be. The key is to separate the
"presentation / presentation logic" and the "business logic / backend code",
or whatever you want to call them. The "presentation logic" can either be
Smarty or PHP.

The problem is that if you use PHP, you must be very aware of what's going
on and ensuring you're keeping the two layers separate. It takes some
dedication. Smarty, however, FORCES you to keep the two layers separate and
I think that's why it's liked by many people. I personally think that Smarty
let you put _too much_ logic into the presentation layer, but everyone's
needs are different.

Smarty has two benefits to using a PHP templating solution (imo)

1. Smarty forces you to keep the presentation layer separate from your
code/business layer.
2. Caching

---John Holmes...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to