Comments on: PHP as a template language

By: Tomasz Jędrzejewski

Tomasz Jędrzejewski — Wed, 03 Nov 2010 06:44:36 +0000

In my opinion, if we decide to use other-than-PHP template language, we should choose something that really helps, not just replaces to { … } like Smarty does. Such template engines not only don’t solve any problems, but also introduce new ones by their esoteric syntax and limitations. I.e Smarty 2 could not execute normal expressions in normal way, but forced to use some weird replacements like {math} instruction or “modifiers”, not mentioning complete lack of tools for making modular templates. These drawbacks are fixed “now”, in Smarty 3, 5 years after other template engines noticed the need to introduce such things!

Some logic is always necessary in templates, it cannot be fully separated, unless we want to have 19281 templates for the same page, for every possible case. The point is to understand what is a presentation logic and what is business logic. The first one in templates is OK, second one – not. Template engines should ease writing presentation logic by introducing specialized instructions etc. not just give loops, ifs and that’s all. Good examples that there is another way are PHPTAL and more advanced Open Power Template 2. Both of them use XML templates, validate template syntax on the fly, and provide some high-level abstractions to the ordinary control programming structures which simplifies writing templates. In OPT, the template is even separated from the real nature of data passed from PHP to it, i.e. you do not have to worry if this is an array, object or something else, and if it is a loop, how the sub-rows are actually represented. In pure PHP and Smarty this is hardly possible.

By: Faltzer

Faltzer — Fri, 30 Jul 2010 17:51:03 +0000

Smarty is terrible; any templating engine that effectively evaluates PHP code is bad anyway. Hence why SUIT is better suited for the purpose of templating, because there is true separation of logic involved, and far less chance of security being compromised should an attacker gain access to your templates.

By: Fedor

Fedor — Sun, 11 Apr 2010 16:27:34 +0000

Smarty sucks!!! So much code for so little.

By: Hirvine

Hirvine — Mon, 15 Feb 2010 14:57:17 +0000

ah form removed my php tags completely, but you get the idea I think

By: Hirvine

Hirvine — Mon, 15 Feb 2010 14:55:19 +0000

True, about messed up PHP, but your example actually shows a poor controller.
A controller shouldn’t use the same view for an error and valid xml.
On the other hand, if I don’t retain the `error` message idea, you may tell blank error message is no error. Which would preserve a single view. Short-tags is indeed irritating here. Mine would look like.

Valid

”
” />

Error

”
” />
” />

It also fixes your missing ‘<’ in front of the order id element.
You have also missed the self closing slash on order id element.

Clearly Smarty didn’t helped you to find those format errors. So no “Easy to Use and Maintain” story for Smarty.

Hey don’t get me wrong. It is what @Manes tells. Using smarty is depended by situation and business. Among friends PHP would do the trick, among a big business which uses different frameworks/cms you may think using template systems.

By: PHP as a template language « Aljo Guts

PHP as a template language « Aljo Guts — Mon, 15 Feb 2010 14:40:11 +0000

[...] Latest news) One of the great debates in the world of PHP – is the language by itself a good templating language (versus using something like Smarty)? I think I’ve said it before. The tool you use should [...]

By: 網站製作學習誌 » [Web] 連結分享

網站製作學習誌 » [Web] 連結分享 — Sat, 13 Feb 2010 14:16:42 +0000

[...] PHP as a template language [...]

By: Manes

Manes — Sat, 13 Feb 2010 12:24:41 +0000

I agree with the point that the adoption of a technology depends on the business requirements: if you think Smarty is the right tool for the job when why not use it?
Nevertheless, I don’t see why a developer shouldn’t look at the disadvantages of using such tool. I have never come across a website about any piece of software that lists its disadvantages and I am not surprised. I mean, why would you want to list the disadvantages of the product you’ve been working on? You don’t need a degree in marketing to answer this question.
Perhaps some really frustrated developer took the trouble to create nosmarty.net, maybe when he chose Smarty as the templating engine to use in production he had only looked at the advantages of it, whereas back then he needed to look at the bigger picture and maybe today he would have been a lot happier had he not chosen Smarty.
I have used Smarty in the past and I personally think it’s not bad, it did the job back then, but I wouldn’t use it again today, I’m looking at alternatives such as PHPTAL: the logic is tightly integrated with the markup thus forcing you to write clean XHTML. Isn’t that better? Plus, I saw Smarty code producing JavaScript code, XML feeds, documents later converted into PDFs. I know I am repeating myself, but when we all say we should use the right tool for the job, then why use Smarty to produce JavaScript code, XML feeds, documents? Any JavaScript library (Prototype, jQuery, etc.), the DOM extension and the PDF extension all seem to be better tools for the aforementioned examples.
This is my humble opinion, feel free to disagree.

By: Sugar Developer Blog » Blog Archive » Smarty or PHP as a templating language?

Fri, 12 Feb 2010 20:49:03 +0000

[...] came across an interesting post by Ibuildings CTO Ivo Jansch, talking about the use of Smarty as a templating language over PHP [...]

By: drm / Gerard

drm / Gerard — Fri, 12 Feb 2010 16:32:06 +0000

Wow, this template discussion might surpass HipHop in the topic-of-the-month award in the PHP community ….

Ivo, I wholeheartedly agree with your post. When I saw the replies on my own blogpost about Twig, I started pondering about starting a site “nonosmarty.net”, which would explain why *every* *single* point displayed on nosmarty.net is either biased or off topic. You point it out well: it is not about whether PHP as a template engine is wrong, it is about why another template engine would be a better fit for your needs. Emphasis is on “FIT”, not on “BETTER”.