Do you use Smarty for templates, or did you write your own parser?
Is Smarty something I should learn to work with?
What are the benefits of smarty?
Wat are the downsides?
Smarty…eh no. That is based on old thinking and development practices.
If I had to pick a pre-made template engine versus building my own I would have to go with Twig.
I created my own. I generate all of my content in php to save me learning any template engines language and then pass it to my own function which then merges it into the template.
Thanks for replies!
Smarty 3 is a complete rewrite with new features such as template inheritance that may be worth a look.
There was a good topic here: http://www.sitepoint.com/forums/f34/showthread.php?t=726580 discussing the merits of templates 
I read that smarty was not a good choice to use,is smarty 3 worth?
I have not use any template engine but I am thinging to learn one.
I use Dwoo in a number of projects.
It has Smarty-like syntax, but seems quite a bit faster and it fully leverages PHP5’s OO capabilites. I love it!
I use php. It has lot of good things for a template engine.
Smarty 3 is completely rewritten for PHP5 OO and has many new features like template inheritance. That feature alone is a game changer. The upcoming 3.1 release has many internal performance improvements and several UTF-8 compliance updates.
That doesn’t say anything regarding its usefulness or whether it’s solving a real world problem though does it? Are you a smarty developer, mohrt? You pop up in template related topics just to mention that smarty 3 is better. Wordpress 3 is “better” than wordpress 2, that says nothing about how it applies to the real world or whether there is actually any benefit of its use, when it should be used and its relative efficacy compared to alternatives.
Yes I am a developer, I think I’ve made that clear. As for its usefulness and real world problem solving, there is plenty of information on the website to to answer these questions. I typically interject here when ignorant assumptions are stated: “smarty sucks” or “smarty is old thinking”, just how are these claims backed up? They are just opinions.
So to answer your questions, instead of repeating what has already been written, here are some resources:
How does template inheritance solve real world problems?
How is Smarty 3 better than Smarty 2?
When is Smarty a good fit, and when it is not?
Oh I agree that frivolous claims like “smarty sucks” are unfounded and offer nothing to the discussion but claims that the new version is “better” are equally pointless because neither address any of the issues at hand.
Don’t get me wrong I’m not saying there’s no place for smarty or any other template engine, I, like you, would rather see a discussion addressing specific criticisms rather than absurd generalisations.
I have no major issue with smarty per se but the way it tends to be used with a huge amount of binding logic does irk me.
My issue with template engines (Both in php and custom syntax) is one of separation of concerns. Placing logic which is grounded in business logic such as “Is the user an admin” in templates causes maintainability issues and placing any kind of logical construct in the template causes potential reusability issues. Which is something I explained in the previous topic. Smarty and other custom-syntax template engines are actually be in a better position to solve this but as it stands still encourage the practice of accessing business level logic and data directly.
By the way, I still can’t see how template inheritance is beneficial in any real-world architecture. Your javascript example would be better represented by passing a list of required javascript and CSS files and looping through them in the template.
The other examples just seem to be a more complex alternative to simple variable substitution. As far as I can tell, if it is solving a real problem, it’s a problem created by smarty itself.
TomB,
Firstly, thank you for the informative and constructive reply!
As for inheritance: The example given is only there to show the implementation of inheritance itself. Yes you can assign CSS/JS and loop it in the traditional template-including design, and there are many ways to skin a cat.
However, template inheritance does have a nice benefit in overall design. The point is that templates can inherit each other, be efficiently reused and redefined by children templates. This is very similar to the benefits of PHP object inheritance, but applied to templates. Django for Python has a very good explanation of template inheritance and the benefits:
http://docs.djangoproject.com/en/1.2/topics/templates/#template-inheritance
As for separation of concerns: This is a larger matter of the developer’s application design. For instance, {if $is_admin} in a template would not be a preferred method, but instead {if $show_edit_controls} would be a much clearer separation. There are even explicit examples of this $is_admin situation on the website, maybe you read this differently? Smarty will not enforce how you design your separation for you, but the website has many informative posts on this topic.
As for solving real world problems, how would you solve:
*) template functional sandboxing (ie. no PHP)
*) template granular caching (no heavy development required)
*) template syntax intuitiveness for non-techies ( {tags} vs php statements )
I understand that these three examples are things that may not be important for some, and may be handled by other means such as custom code or other libraries. However these are examples of real world problems solved by Smarty, not created by Smarty. Whether Smarty fits your needs are dependent on your own requirements and preferences. It’s not a tool for every job, and was never intended to be.
Even reading the Django documentation I fail to grasp where template inheritance would be preferable to simple variable substitution where the variables have a default value. At least with variable substitution you have the option of replacing the block form any source, whereas using template inheritance, as far as I can tell, you lock yourself in to that methodology. Which reduces template reusibility.
On separation of concerns, I explained my main issue here: http://www.sitepoint.com/forums/showpost.php?p=4788275&postcount=14 This is not an issue with smarty, but neither is it one smarty attempts to solve.
I’d rather have a more complex application where the display logic is in a totally separate file to the template. This allows for the same logic to be applied across different templates or the same template to be re-used with different logic.
Smarty moves the logic from the template to the template. Admittedly, when people are going from mixed business logic and display logic smarty helps people think about what they’re doing, but as a template engine on it’s own the benefits over just using PHP seem to only apply to cases where non-trusted users are editing the markup.
I’d just like to clarify one of my main annoyances with the use of template engines. Code like this makes me cringe:
$template->assign('firstname', $user->firstname);
$template->assign('lastname', $user->lastname);
$template->assign('email', $user->email);
$template->assign('address1', $user->address1);
//etc
Again, not specific to any particular implementation but I see it enough to be frustrated by it 
template syntax intuitiveness for non-techies ( {tags} vs php statements )
I’d still list this as debatable. Some smarty syntax seems terribly complex even to the point of looking more confusing than looking at the same PHP code.
My suggestion of separating the logic to a totally different file and having simple marked up sections would actually improve this and still give the developer control over the logic and the designer control over the look. As I’ve said previously, it’s comparable to inline styles vs external stylesheets.
template granular caching
There are many ways to implement caching in php, I fail to see how this is a problem at any stage using any template system (php or otherwise).
template functional sandboxing
This is the only point I can see where it would be required. However, looking at the syntax for it, it’s as complex as PHP so the only advantage is security and again I think the practical applications for this are somewhat limited to cases where standard users are editing the markup.