Wow – yet another Smarty “defector”. I’m saying that at least somewhat sarcastically. Personally, I think Smarty’s done more damage to the PHP web dev community than almost any other project. It’s added more extra work for comparitively little return relative to the energy expended. I can’t tell you how many times I’ve been on a project and had to relearn how to deal with arrays or objects or whatever in the template when using Smarty. It’s *yet another language* to deal with. I prefer using fewer languages rather than more on a project, especially when PHP itself can do everything Smarty can (with the exception of restricting access to functionality).
Had the Smarty syntax made the jump to other languages, such that you could reuse Smarty templates in Python, Java, .NET, etc., it might have been worth it. But it was too closely tied to PHP to ever make that jump.
Who else has made the decision to reject Smarty? How long did it take you to reach that decision? What’s your alternative approach?
I’ve also moved my position away from separate templating languages towards using PHP, but I’m not absolute about that. I think that PHP offers a number of useful features that I wind up poorly re-implementing in whatever template language I’m using.
Still, there are still valid reasons for a project to use Smarty. If I were to create a blog hosting service I would probably use Smarty to let users customize their templates without exposing dangerous PHP functions.
I also accept that some people are more comfortable working with sandboxed templates. When Paul Jones says it’s a management problem, that’s sort of dismissive. I imagine someone saying “Well you’re a smart, talented client side coder but I’m going to force you to use my tool because it’s what I’m comfortable with.” I’d rather see smart people use the tools that they are most comfortable with. From the business logic side I should be able to encapsulate my views to the point where it doesn’t matter if renderPage() runs a PHP script or passes a bunch of arguments to Smarty.
If you’re looking for an HTML templating language that is available in multiple languages, you might want to learn TAL. It’s valid XHTML, it uses XML attributes for commands, and uses the XML tree structure for conditional and looping blocks. It’s also available on a number of different platforms, including Java. PHPTAL’s introduction gives a good overview of how it works.
I know you’ve promoted TAL for years, and I respect that. Mostly because it *IS* cross-platform. You have a skill that transfers, and expand the available pool of talent to draw from.
I was probably overly confrontational in the post. Yes, there are a few situations where a templating system makes sense. For most people’s projects, it’s a waste. The ‘hosted service’ projects are, in the grand scheme, imo, exceptions. So learning and basing all your work on something which is primarily suited for exceptions is a waste of time for most people. If you *know* you need it, you’re far enough along to understand your use case and your needs. But blindly getting behind Smarty and using it ‘because now I’m separating things!’ in and of itself is bad. I’ve worked with too much crappy code in the past few years, and Smarty has generally been involved in the mix. I don’t think I’ve personally worked on a project with ‘good’ PHP which also used Smarty. Just my experience tho.
I’ve only used Smarty when having to modify some third party applications. It’s not really that bad if used properly but it’s a pain when people try to do almost everything with it.
Using PHP as the template syntax is all right but I find it too ‘imperative’.
TAL however is awesome, not just because it’s quite similar to HTML syntax but because of the no non-sense features. Every now and then you find something difficult to implement with TAL and that is its greatest feature, since it allows you to think about it and take a better approach to the problem. I like it so much that implemented a javascript version, it makes working with HTML on JS much nicer for me.
I really wish PHPTAL supported php4 too. I’ve looked at the code and it’s not using anything specific to 5. I tried to back port it but it took more than 5 minutes so I stopped. Now, a year or two later, I guess I can live w/o php4 support, but it just bugs the crap out of me when people force php5 on you and then they don’t use any new features, just crappy public/private accessors.
DrSlump – I agree it’s a pain when people try to do everything with it. however, if you don’t, then what’s the point of using it? If you’re just doing variable replacement, it’s not that different from just passing an array of values in to a PHP file. Yes, Smarty has a few nice text modifiers, but ultimately that doesn’t justify its use in my view.
Thanks for the comments.
I find it quite funny how all people recently bash on Smarty and no one says anything about typoscript, which imho is much worse.
Even restricting functionality can be done in PHP with the pecl extension runkit (as well as some other crazy stuff)
@marc – certainly doing it at the smarty level might be easier in some cases, especially shared hosting, but yeah, you’re right.
@fa – not sure if that was directed at me or not. I’ve complained about Smarty for years, this isn’t a recent thing for me. And I doubt most people have even heard of typoscript – I certainly haven’t. Any ‘templating’ system on top of PHP is, imo, a waste, unless you’ve got clearly defined business rules which can be justified only by employing one. I’ve run in to precious few cases where it was a good choice.
This reminds me a bit of the arguments over JSTL in Java. A lot of your criticisms of Smarty could also be aimed at JSTL. I’m all in favor of separating code from presentation, but things like Smarty and JSTL often end up turning into code. I think HTML templating langugaes should be very limited, to prevent abuse. Also, HTML templates should have default values so they can be viewed in a browser and have some resemblance to the running app, and also to support working with HTML designers.
All of these issues were dealt with years ago by Apple’s WebObjects in a very elegant fashion. I can’t understand for the life of me why their approach hasn’t been more widely imitated.
I once tried not to use Smarty – designers from my company still curse that day as they simply wasn’t able to handle all the things like <?php ?>, echo, $this->var, etc. Reallity bites
I work with Smarty 5 days a week.
I like Smarty.
For a green programmer it allows easy access to caching, and if well used I think very much helps with separation of logic and presentation.
I don’t think Smarty brings much to the table for experienced programmers, but for those that are green, I think it is useful.
Thanks Rob. I would classify your ‘green programmers’ as another exception case. I do appreciate your view on this and thank you for your comment.
“Green programmers”, “html designers”, “templaters”, all of these words denote a development environment where you cannot afford to have a small group of very efficient coders doing everything, and you have to ship off the ‘easy’ task to a set of less-skilled (or differently skilled) workers.
Reasons might include:
- you are not hiring them, and the company who is always goes for cheapo
- you are churning out a website a month, and have to ave 30+ people working on html. 30, or even 15 real coders will cost you way too much.
Whether Smarty or another template language is used, the main goals are to
1 – prevent the designer from fscking up your web page and whole app with a bad line (and php is lousy at that, no concept of security rings, limited resource quotas, poor implementations in the past of restricting access to functionality)
2 – help designers giving them access to something which looks “more like html”. If they know already php it’s a waste of time, but if the do not, they are gonna like your templating language a lot more than your programming language
All in all, only extremely good architecture and overly rigid development rules will prevent the templating code to incorporate a good chunk of business logic.
@Rob
I really can’t see how Smarty “helps with separation of logic and presentation” in any other way than it makes you use a template so your are not so easily tempted to echo “.
I really like how so many people have written about Smarty lately. Hasin Hayder mentions how the vast variety of MVC (or MVC’ish) frameworks out there provide a solid structure for the separation of logic and presentation and how just this is the reason why Smarty can be abandoned. This is something that should be stressed more and let all the “green programmers” know that rather than learning a second template language to be used with PHP they should pick a framework and learn how a clean design can help in keeping templates simple and maintainable.
uups, html tags are obviously stripped rather than encoded.
should have been:
“.. are not so easily tempted to echo “<html>” “
Personally I never even bothered with Smarty when it first emerged, it’s all in the name anyway; any script, application or service that needs to tell you it’s “smart” through it’s name obviously isn’t.
That and that I much preferred something more lightweight like Savant.
And “green” programmers belong in school with a capable teacher rather than in a company where they can do damage which will have to be corrected later at great costs.
> Who else has made the decision to reject Smarty?
I did!
> How long did it take you to reach that decision?
About half a year, after using Smarty in a large university project. You are absolutely right, Smarty is a whole language by itself, with a nasty contrived syntax.
> What’s your alternative approach?
Savant (or just plain PHP), implicitly so in the SolarPHP framework
@fa the reason nobody picks on typoscript because nobody’s boss has the bright idea to force all their developers to use it against their own better judgment.
@Gaetano Giunta – I agree with everything you said (mostly (at least the parts that I read)). The problem comes when people think smarty is a solution, or a requirement, for templating. Most people just say, “gosh, how do you not make crap applications then?”. Which generally angers the coder who has been making applications long before Smarty was out. So, smarty gets a lot of flack merely because it’s controversial and misunderstood, not because it’s incredibly bad or anything (but it is).
Since someone mentioned Typoscript (Typo3) already – I think what you experienced with Smarty is exactly how I feel about that. I wouldn’t bash either because obviously both seem to serve people where others totally reject them.
On any rate. I still sometimes use Smarty. It’s pretty elegant with the caching and the syntax is dead-simple. In fact most designers I have worked with no how to deal with it and if not there are some excellent docs that will.
Btw, in regard to objects and array – I see what you are saying, if all fails, I resort to {php} inside the template and in the end I refactor those and write custom modifiers or inserts to get done what I need.
no = know
@ mgkimsal
If only green PHP programmers really were the exception… Like it or not there are many inexperienced or just plain bad programmers out there.
@Veikko Mäkinen
And those greed programmers often put echo’s in inappropriate places. Would you rather clean up a mess made in pure php with no separation, or a mess in smarty with at least minimal separation?
@Ensiferous
I think part of the reason PHP is as popular as it is, is because of the low barrier to entry. I would venture a guess that a majority of PHP programmers have not had formal training. C’est la vie.
I think the ease of caching is significant.
We(at my job) have also moved to raw PHP usage in templates, however we really needed some syntax sugaring for PHP constructs in order to make templates more readable for designers.
That’s why we hacked {{macro}} – quite flexible and extensible template engine which uses C/C++ alike(but way more sophisticated) macro tags to simplify usage of raw PHP in templates.
{{macro}} tags generate PHP code during template compilation stage which may seem a bit “Smartish”. However, unlike Smarty, {{macro}} doesn’t try to “hide” PHP from the template designer: it just makes its usage more convenient and you always have an option to use PHP in parallel with macro tags. Furthermore, you can endlessly extend {{macro}} with your own tags, in fact, all core {{macro}} tags are not hard-coded as special cases as well.
If you are still reading and interested in {{macro}}, it is available over SVN(https://svn.limb-project.com/limb/3.x/trunk/limb/macro/) and I blogged a little more about it here http://efiquest.org/2007-11-04/14/
@mgkimsal
I’m with you on Smarty. I used to use a framework called WACT but have since ditched it as its not actively maintained.
WACT has a template language similar to TAL.
For my latest project, and not too enthusiastic about any of the other PHP frameworks, I decided to go framework-less and roll my own “skeleton.”
Initially I wanted to revisit using PHP as the template language.
And the point? Well.. this is in response to you saying most projects don’t need a template language beyond PHP itself.
No, they don’t *need* it, but templates are a hell of a lot more readable when you have a concise template language.
Fact is, you can’t run with short tags on anymore. As such, variable substitutions are so long-winded. Common and logically simple use-cases like displaying a list if it exists, or something different if it doesn’t can look like a total mess:
0) { ?>
<img src=”" />etc..
ain’t no records
Yeah you can kill a few open/close PHP tags in the inner loop by echoing the entire line, but:
a) that breaks syntax highlighting in some editors
b) it still looks messy, IMO.
Compared with WACT’s tag-based templates:
{$field1} etc..
ain’t no records
Much more readable IMNSHO. Much more editor friendly. It enforces the presentation-layer separation by not allowing you to slip in any explicit logic. htmlspecialchars() is done behind the scenes. Caching of the final markup is an option just as with Smarty (in PHP you’d have to roll your own).
Interested to know what you think about these comments. I assume TAL has all the functionality of WACT’s template system and so I’m off now to give it a try!
[second attempt, with pre tags this time!]
@mgkimsal
I’m with you on Smarty. I used to use a framework called WACT but have since ditched it as its not actively maintained.
WACT has a template language similar to TAL.
For my latest project, and not too enthusiastic about any of the other PHP frameworks, I decided to go framework-less and roll my own “skeleton.”
Initially I wanted to revisit using PHP as the template language.
And the point? Well.. this is in response to you saying most projects don’t need a template language beyond PHP itself.
No, they don’t *need* it, but templates are a hell of a lot more readable when you have a concise template language.
Fact is, you can’t run with short tags on anymore. As such, variable substitutions are so long-winded. Common and logically simple use-cases like displaying a list if it exists, or something different if it doesn’t can look like a total mess:
Yeah you can kill a few open/close PHP tags in the inner loop by echoing the entire line, but:
a) that breaks syntax highlighting in some editors
b) it still looks messy, IMO.
Compared with WACT’s tag-based templates:
Much more readable IMNSHO. Much more editor friendly. It enforces the presentation-layer separation by not allowing you to slip in any explicit logic. htmlspecialchars() is done behind the scenes. Caching of the final markup is an option just as with Smarty (in PHP you’d have to roll your own).
Interested to know what you think about these comments. I assume TAL has all the functionality of WACT’s template system and so I’m off now to give it a try!
[third attempt, manually encoding my markup. suggestion: add a preview comment option]
@mgkimsal
I’m with you on Smarty. I used to use a framework called WACT but have since ditched it as its not actively maintained.
WACT has a template language similar to TAL.
For my latest project, and not too enthusiastic about any of the other PHP frameworks, I decided to go framework-less and roll my own “skeleton.”
Initially I wanted to revisit using PHP as the template language.
And the point? Well.. this is in response to you saying most projects don’t need a template language beyond PHP itself.
No, they don’t *need* it, but templates are a hell of a lot more readable when you have a concise template language.
Fact is, you can’t run with short tags on anymore. As such, variable substitutions are so long-winded. Common and logically simple use-cases like displaying a list if it exists, or something different if it doesn’t can look like a total mess:
<?php if (count($recordset) > 0) { ?>
<ul>
<?php foreach ($recordset as $record) { ?>
<li><?php echo “$record[field1]“?><img src=”<?php echo “$record[field2]“?>” />etc..</li>
<?php } ?>
</ul>
<?php } else { ?>
<p>ain’t no records</p>
<?php } ?>
Yeah you can kill a few open/close PHP tags in the inner loop by echoing the entire line, but:
a) that breaks syntax highlighting in some editors
b) it still looks messy, IMO.
Compared with WACT’s tag-based templates:
<list:list id=”mylist”>
<ul>
<list:item><li>{$field1} <img src=”{$field2}” />etc..</li></list:item>
</ul>
<list:default><p>ain’t no records</p></list:default>
</list:list>
Much more readable IMNSHO. Much more editor friendly. It enforces the presentation-layer separation by not allowing you to slip in any explicit logic. htmlspecialchars() is done behind the scenes. Caching of the final markup is an option just as with Smarty (in PHP you’d have to roll your own).
Interested to know what you think about these comments. I assume TAL has all the functionality of WACT’s template system and so I’m off now to give it a try!
Having looked over my previous comment, I realise I may have come across as totally closed off to the idea of using pure PHP for templates. I’m not. If I can simplify my framework/skeleton to one language instead of two, I’d love to do so.
I would really like to see some example code from anyone advocating PHP for templates (aside from Rasmus’ no-framework blog post). Specifically what I’m interested in seeing is:
a) where you call htmlspecialchars/htmlentities
b) whether you include the template from the controller, or vice versa.
Would you please take the time to post a short example?
can become
and the same goes for everything else – if statements, loops etc..