|
Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon. |
|
View previous topic :: View next topic |
Author |
Message |
mohrt Administrator
Joined: 16 Apr 2003 Posts: 7368 Location: Lincoln Nebraska, USA
|
|
Back to top |
|
dilvie Guest
|
Posted: Fri Apr 25, 2003 4:54 am Post subject: nice article |
|
|
Cool article, and if your designers are all coders, I might agree. However, the smarty template syntax is well worth it for me. It would be wise also not to forget Smarty's speed optimizations. It's a lot of extra crap, sure, but it makes it very easy for other people to modify the templates, and when they're done tinkering, the caching features come in and effectively make smarty powered pages nearly as fast as straight HTML. For those of us with limitted server resources who want easy-to-manage, data-driven websites without much added overhead where lots of other people (possibly co-workers, likely CLIENTS themselves) need to be able to understand and modify the templates, Smarty is hard to beat. I haven't seen anything better yet -- but I'm still open to alternatives. As long as it's not a step backwards.
- Eric |
|
Back to top |
|
sstewart0nz Guest
|
Posted: Fri Apr 25, 2003 9:00 am Post subject: PHP is a templating engine |
|
|
This argument is going to continue forever. As with most software, it's about the design of it. All that Smarty and other engines like this do is try to force you to design your application in a particular way. Period.
You can do just the same sort of thing in PHP (or ASP or JSP). If your designers are using half decent tools, they can probably make the PHP code look like comments, therefore not viewing it and consequently not being "overawed" by it all. And in my books, if they cannot read a foreach() or an if(), then they should take lessons in how to tie their shoes: "foreach shoe, tie the lace - if the lace is already tied, don't tie it again".
I know nothing about Smarty, but I dare say that it will most likely let you put some sort of business logic in with your presentation logic. It is code after all: if it's got for loops and if statements it can be butchered by bad design.
Use a good design and a dose of common sense and no matter what technology you use, you'll come out on top. |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri Apr 25, 2003 5:22 pm Post subject: |
|
|
A compelling article that completely misses one of the more important aspects of template languages: vocabulary and syntax. It may be quite fine for a computer to switch contexts one character to the next and a compiler may think nothing of the trickiest syntax passes (including intermixed syntax) but I think that humans are best suited to a single flow. By that I mean, we tend to structure environments that are suitable for a specific domain because it allows our thinking process to be dominated by the given task.
Yes, his examples are elegant, but I bet he'll be eating his words about "never going back". Those few extra characters that he mentions make a BIG difference when you are looking at code day in, day out. That's why XML derived languages suck so bad for users but are so loved by computers--they require too much brain processing to be useful for everyday work and unfortunately, so does PHP intermixed with html. Especially since you are GOING to intermix templating code needs with application code needs. So who owns the file, the code monkey or the design monkey?
When I first started to code, it was in assembly and I still see the need for assembly. But for everyday tasks, I'm going as high up the abstraction layers as possible and intermixed html/php isn't even close to being there.
He does make a good point though about Smarty essentially being a wrapper around PHP. I think template engines need to start providing semantics more close to their intended use than their underlying structure. Smarty makes big steps in that regard but some important things are missing. For example, we still need to write loops in smarty to support concepts like tables. Wouldn't it make sense if template languages provided semantics to DEFINE the table portions (dimensions, row types, cell types, titles, blah) with the engine writing the appropriate loops?
He'll be back |
|
Back to top |
|
mohrt Administrator
Joined: 16 Apr 2003 Posts: 7368 Location: Lincoln Nebraska, USA
|
Posted: Fri Apr 25, 2003 9:47 pm Post subject: |
|
|
boots wrote: |
He does make a good point though about Smarty essentially being a wrapper around PHP. I think template engines need to start providing semantics more close to their intended use than their underlying structure. Smarty makes big steps in that regard but some important things are missing. For example, we still need to write loops in smarty to support concepts like tables. Wouldn't it make sense if template languages provided semantics to DEFINE the table portions (dimensions, row types, cell types, titles, blah) with the engine writing the appropriate loops?
|
That is where custom functions come into play. Example, the {html_table} function (new to 2.5.0) takes steps to make table generation automated rather than doing things by hand with loops.
Monte |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri Apr 25, 2003 10:37 pm Post subject: |
|
|
Quote: | That is where custom functions come into play. Example, the {html_table} function (new to 2.5.0) takes steps to make table generation automated rather than doing things by hand with loops. |
I realize that and revere plugins for that ability (I've said as much in other posts) but it only allows that convenience through attribute settings. Often times that is not nearly enough. Eg, there is no logical connectedness between block functions eg.
{table....}
{row}
{/row}
{/table}
except for the fact that I wrote the {row} inside of {table}, {row} doesn't semantically "belong" to {table} as far as Smarty is concerned. There is no hierarchy of tags, so in smarty, I can write my hypothetical {row} block outside of a {table} block even if that has no meaning. Yes, I can write a block function that implements a custom language parser (and have done so, often) but that sort of seems silly, doesn't it?
Anyhow, I think Smarty offers so much out of the box that for it to be compared to the style in the article (especially for the example given) is laughable. |
|
Back to top |
|
dthought Smarty Regular
Joined: 21 Apr 2003 Posts: 55 Location: Melbourne, Australia
|
Posted: Sun Apr 27, 2003 10:20 am Post subject: |
|
|
Hrm, not the best article I've ever read. The author starts off insulting things, then says that Smarty does things sort of right but he doesn't like it because it's too big. Right. Whatever.
But the proposed solution is typical of a hardcore PHP code. Sure, it might be "elegant" and "fast", but it's totally ignorant of a designer who works primarily with HTML and interface design. Let's consider some of the examples and their Smarty-readable equivalents. Second one first:
Code: |
<html>
<head>
<title><?=$this->get('title');?></title>
<link href="style.css" rel="stylesheet" type="text/css" />
</head>
<body>
<h1><?=$this->get('title');?></h1>
<?=$this->get('content');?>
</body>
</html>
|
Might be all fancy schmanzy PHP, but have a look how much godawful punctuation is in there! All sorts of nasty question marks, equals signs, a > which, by pure reading, breaks if it were plain HTML (and hence, may break visual design programs such as Dreamweaver). From an interface designing point of view, this code is heinously unusable and confusing. Consider a Smarty equivalent:
Code: |
<html>
<head>
<title>{$title}</title>
<link href="style.css" rel="stylesheet" type="text/css" />
</head>
<body>
<h1>{$title}</h1>
{$content}
</body>
</html>
|
I know which one I'd rather read. His examples fall apart to the point of collapsing when some more complex logic is introduced, as in the first "template" *cough*:
Code: |
<table cellpadding="3" border="0" cellspacing="1" bgcolor="#CCCCCC">
<tr>
<td bgcolor="#F0F0F0">Id</td>
<td bgcolor="#F0F0F0">Name</td>
<td bgcolor="#F0F0F0">Email</td>
<td bgcolor="#F0F0F0">Banned</td>
</tr>
<?php foreach($this->get('users') as $user) { ?>
<tr>
<td bgcolor="#FFFFFF" align="center"><?=$user['id'];?></td>
<td bgcolor="#FFFFFF"><?=$user['name'];?></td>
<td bgcolor="#FFFFFF"><a href="mailto:<?=$user['email'];?>"><?=$user['email'];?></a></td>
<td bgcolor="#FFFFFF" align="center"><?=($user['banned'] ? 'X' : '&');?></td>
</tr>
<?php } ?>
</table>
|
Let's play a game - it's called read the section blocks! Finding a missing { or } inside a complex code block of this nature would be nothing short of nightmarish. Shorthand if statements? Exactly how much is an interface designer going to be willing to learn for this templating system? Let's try a Smarty-readable equivalent, assuming users are stored in a standard numbered array (as opposed to an associative one):
Code: |
<table cellpadding="3" border="0" cellspacing="1" bgcolor="#CCCCCC">
<tr>
<td bgcolor="#F0F0F0">Id</td>
<td bgcolor="#F0F0F0">Name</td>
<td bgcolor="#F0F0F0">Email</td>
<td bgcolor="#F0F0F0">Banned</td>
</tr>
{section name=curuser loop=$user}
<tr>
<td bgcolor="#FFFFFF" align="center">{$user[curuser].id}</td>
<td bgcolor="#FFFFFF">{$user[curuser].name}</td>
<td bgcolor="#FFFFFF"><a href="mailto:{$user[curuser].email}">{$user[curuser].email}</a></td>
<td bgcolor="#FFFFFF" align="center">{if $user[curuser].banned}X{else}&{/if}</td>
</tr>
{/section}
</table>
|
So, which would you rather read?
Oh, another fun shot often fired by these crazed coders is that the template tags for Smarty are { and } by default, which - shock - is not XHTML compliant. They obviously are oblivious to the fact that you can tell Smarty to interpret its opening and closing tags how you wish - you could use <? and ?> if you wanted, or maybe even <{ and }> - but in my experiences designing interfaces with Smarty, I've found that working with Dreamweaver and standard curly braces is great. |
|
Back to top |
|
Wom.bat Smarty Pro
Joined: 24 Apr 2003 Posts: 107 Location: Munich, Germany
|
Posted: Sun Apr 27, 2003 10:42 am Post subject: |
|
|
the primary reasons why I prefer Smarty over pure PHP templates are:
1) most things are easier in templates (think of {$foo|truncate:30:"..."} which would need several ifs and so on in PHP)
2) it's a complete, ready-to-use, stable application
3) things like caching, filters and other damn useful features would take a lot of time to implement in an own pure PHP template class
4) it's insanely fast, as it compiles templates
5) plugins, filters etc make it extremely customizable
6) it's LGPL
7) the developers are cool guys |
|
Back to top |
|
Brian Smarty Rookie
Joined: 29 Apr 2003 Posts: 21
|
Posted: Tue Apr 29, 2003 12:25 am Post subject: |
|
|
Hey everyone! Imagine my surprise when I saw that my article was posted on smarty.php.net I am the author of that article and I wanted to respond to some of your points. I don't really have time right now to go all out but here's a bit... BTW: I don't hate smarty. I have used it in a lot of projects. In fact, the rather large company I develop for is using it currently for our so-called "enterprise CMS" (actually, I'm an outside contractor hired to help with it).
Quote: | Yes, his examples are elegant, but I bet he'll be eating his words about "never going back". Those few extra characters that he mentions make a BIG difference when you are looking at code day in, day out. |
Yes, that $this-> syntax SUCKS. I will be updating the article to remove it. All it takes is a simple extract() call inside the fetch() method to remove it altogether. So the new syntax is:
<?=$var;?>
<?php foreach($var as $value) { ?>
blah blah
<?=$value;?>
<? } ?>
I have implemented a better version in 36 lines of code. I have added caching very similar to smarty (pass a cache_id and use an is_cached() method) in less than a hundred lines of code.
No, you don't get the simplicity of plugins yet. No, I don't recommend you use my method if you need that plugin capability. However, it would be extremely easy to devise a "standard" plugin interface for the method described in the article. Is it really easier to type {datepick} than it is <?=datepick();?> ? Even if it is easier, is it worth the speed decrease (smarty vs native php)? PHP comes syntax-highlighted in virtually every modern editor, so there, it may even have an advantage.
Syntax is syntax. A designer will have to learn something new either way. I haven't seen a designer struggle with either <?=$var;?> or {$var}. The foreach thing seems a wash, too. Plugins are debatable (but why bother>?). Caching and standardization are big -- hell, I got my job partly because, unlike some other applicants, I had extensive experience with smarty.
I wasn't trying to stir up crap with you smarty people - I was just trying to make a point that template engines should not be designed to separate HTML from PHP, but rather, to separate business logic from presentation [logic]. |
|
Back to top |
|
Brian Smarty Rookie
Joined: 29 Apr 2003 Posts: 21
|
Posted: Tue Apr 29, 2003 12:30 am Post subject: |
|
|
Oops, forgot something. If you are more comfortable with {/foreach} than <? } ?>, you are free to use the alternate control structure syntax as explained here:
http://www.php.net/manual/en/control-structures.alternative-syntax.php
In this case, it would be something like:
<?php foreach($users as $user): ?>
<li><?=$user;?></li>
<?php endforeach; ?>
There is also endif;, endwhile;, etc. |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Tue Apr 29, 2003 2:15 am Post subject: |
|
|
Hi Brian and thank-you for the original article and your comments here!
Quote: | I have implemented a better version in 36 lines of code. I have added caching very similar to smarty (pass a cache_id and use an is_cached() method) in less than a hundred lines of code. |
One of the things about Smarty and to some extent, other template engines, is that on top of the templating capabilities, they provide a set of services and a framework to enable processing to occur in an orderly fashion. As for services, Smarty provides configuration files, templates, compilation, caching, filters, resources, a plugin API, a security model and a slew of provided template functions and modifiers. All of these features are customizable and available out-of-the-box (maintained, tested and documented by a community of developers and users). The caching and security features are important: one speeds up output while the other ensures that only specific funtionality is available to template designers.
All that with a cleaner syntax. The syntax doesn't stop at making <?=$myvar; ?> more readable either. For example, dot notation for arrays and | modifiers are very thoughtful additions within Smarty.
Perhaps Smarty has too many features bundled in one package and could stand to be modularized. Perhaps some things can still be made easier. It is debatable, but never-the-less, with or without a template engine, you will likely want to implement many of the features that Smarty silently provides in your own frameworks. So either you are back to rolling your own libraries (which means your own testing, documentation and maintenance) or you are going to end up using a bunch of public libraries.
Single purpose libraries often have more functions than one would normally need. Having several seperate libraries can lead to bloat and also tends to lead to an optimization problem as resource sharing will have to be managed by you. Smarty's internals are optimized to work together and provide just enough features needed to implement Smarty's services.
Maybe calling Smarty a template engine is a little unfair to other template engines--it provides much more than simple templating features (which as you point out, requires 0 lines of code anyhow since PHP is itself a templater). Smarty looks more like a "programmable output server" but template engine probably sounds friendlier.
Smarty is not right for every job. Is Smarty a bad idea? No way!
Make sure to post back here when you update your article!
ps. I knew you'd be back :evil grin:
Last edited by boots on Tue Apr 29, 2003 4:01 am; edited 1 time in total |
|
Back to top |
|
mohrt Administrator
Joined: 16 Apr 2003 Posts: 7368 Location: Lincoln Nebraska, USA
|
Posted: Tue Apr 29, 2003 3:47 am Post subject: |
|
|
Quote: | Maybe calling Smarty a template engine is a little unfair to other template engines--it provides much more than simple templating features |
That is an interesting spin to put on it, although Smarty at its core is a template system. In addition to simple variable replacement, it provides the pieces that are routinely needed along with simple templates. So instead of having to build home-grown solutions or dealing with "how do I accomplish this with that", they're already provided in a modular, efficient manner.
Well put boots!
Monte |
|
Back to top |
|
Brian Smarty Rookie
Joined: 29 Apr 2003 Posts: 21
|
Posted: Tue Apr 29, 2003 4:01 am Post subject: |
|
|
Quote: | None of the above is feasible when app code and presentation are mixed together. Also remember Smarty compiles the templates to PHP code anyways, so performance isn't much of an argument either. |
In our experience, smarty is a lot slower than about half of the currently available template engines that we have tested, regardless of the compiling. Heck, look at your benchmarks
Quote: | I realize that I separate the programmer/designer roles in these examples. Even though that may not be the case for everyone (programmer/designer same person), IMHO it is still good practice to keep the concepts separate for your own ease of maintainance and future flexability. |
Of course.
Quote: |
I was just trying to make a point that template engines should not be designed to separate HTML from PHP
I respect your opinion, but will have to disagree HTML is markup, part of the presentation, which should not be mixed with the application code. That is the reason to use a template engine such as Smarty. |
You misunderstood what I was saying. There are two types of logic: business logic (db access, application rules, etc.) and presentation logic (display a login box or a logged in message, alternating table/column colors, site "skins" or themes, etc.) - I think business logic should definitely be separated from presentation logic, but there has to be some presentation logic (smarty is full of it). |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Tue Apr 29, 2003 8:49 am Post subject: |
|
|
@Monte:
It looks like you got quoted before you edited your comments out
I thought you made good points! |
|
Back to top |
|
mohrt Administrator
Joined: 16 Apr 2003 Posts: 7368 Location: Lincoln Nebraska, USA
|
Posted: Tue Apr 29, 2003 2:14 pm Post subject: |
|
|
ah, oops. Well the points I made are in the "why use" document, I had just cut and pasted from there. I removed it since boots cross-posted with basically the same concepts but better words |
|
Back to top |
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|