View previous topic :: View next topic |
Author |
Message |
mohrt Administrator
Joined: 16 Apr 2003 Posts: 7368 Location: Lincoln Nebraska, USA
|
Posted: Fri Dec 19, 2003 10:52 pm Post subject: Beyond the template engine |
|
|
Another interesting article about template engines by Brian Lozier. There are plenty of references to Smarty in this one!
http://www.sitepoint.com/article/1218/ |
|
Back to top |
|
ZeroFill Smarty Rookie
Joined: 31 Aug 2003 Posts: 28
|
Posted: Tue Dec 23, 2003 9:45 am Post subject: |
|
|
being somewhat of a regular at sitepoint, that article is how i came across smarty and loved it (smarty) ever since _________________ my delimiters are <{ and }> |
|
Back to top |
|
zbiru Smarty n00b
Joined: 03 Jan 2004 Posts: 1 Location: Poland
|
|
Back to top |
|
mohrt Administrator
Joined: 16 Apr 2003 Posts: 7368 Location: Lincoln Nebraska, USA
|
Posted: Sun Jan 04, 2004 7:14 pm Post subject: Re: Beyond the template engine |
|
|
zbiru wrote: |
There is also very interesting Savant Template System for PHP (http://phpsavant.com/). Like mentioned in articles above, it also uses PHP itself as its template language so you don't need to learn a new markup system. It has an object-oriented system of template plugins and output filters, so it supports almost all of the power of Smarty with almost none of the overhead. |
... and almost none of the features. Just use the right tool for the job. |
|
Back to top |
|
dthought Smarty Regular
Joined: 21 Apr 2003 Posts: 55 Location: Melbourne, Australia
|
Posted: Sun Feb 08, 2004 1:27 am Post subject: |
|
|
Bah, that article was written from the point of view of a programmer. I am not a programmer. He totally trivialises the awful mess that is a foreach statement. There is too much complex, frustrating punctuation in using shorthand PHP, and more room to totally screw it up. PHP is simply *too powerful* to give to someone who does not come from a full programming background (ie. a designer who knows HTML, and let's say some basic Javascript).
Unfortunately it's programmers who tend to write the articles arguing the pros and cons of templating engines, Smarty included.
Now, which is easier to understand from a non-programmer's point of view (I'm going to whack in a full foreach, as I use them all the time at work in Smarty based projects)?
<? foreach($user_list as $user_key => $user): ?>
(code)
<? endforeach; ?>
Wait, endforeach? That's a whole separate word (and knowing PHP's rather all-inclusive PERL / C / C++ / whatever other languages they felt like mashing together syntax, it's likely that there's be something that is written in a different from this, such as maybe it uses the word 'close' instead of 'end'. I wouldn't put it past PHP, that's for sure).
It's so much clearer for a designer to have Smarty lay things out into individual chunks (though Smarty still suffers from the PHP problem of naming inconsistencies, something that I would love to have the team address in a future release)
{foreach from=$myvariable key="mykey" item="mydata"}
(code)
{/foreach}
Having the data separated into three separate, logical options is far, far easier to understand and comprhend than it is to have to grasp => and -> and all those other terribly confusing pointer thingies in PHP.
And writing
<?=$var;?> is far more dangerous and error prone than {$var} because THERE'S ONLY ONE SET OF BRACKETS YOU NEED TO REMEMBER. With the former god-awful syntax, you have to remember not only brackets and question marks, but if you're using a variable, heaven forfend you forget the all-important = sign.
Anyway, that's just my views on some of the points raised in that article. Make of them what you will. |
|
Back to top |
|
gsbe Smarty n00b
Joined: 10 Feb 2004 Posts: 1 Location: Nashville, TN
|
Posted: Wed Feb 11, 2004 12:19 am Post subject: Interesting reading, but... |
|
|
And now, representing the dolts of the world, we turn to Graphic Designer X:
I've read Lozier's article and am happy to report that I understood his points and their benefits. Sadly, I did not comprehend his code examples. I read both of the code examples posted by dthought and neither of them make sense to me, either.
I have no desire to be just another dolt Graphic Designer. I know that programmers are required to know a lot of different languages and tools. The same is true for Graphic Designers, especially those that work with print and web design. Becoming tied to your tools is not a good idea. Its a hard sell to get a designer (and programmers for that matter) to learn a new system when Dreamweaver is working well.
Designers are smart, but not smarties like you programmers. You have an aptly named template engine to prove it. Dreamweaver has shown itself to be a leader in WYSIWYG web design. I love the "separation of business logic from the presentation of data." Now can we just get it to work easily within Dreamweaver?
I realize that I am oversimplifying the issues and might be seen as another dolt designer with a party-pooping, lazy attitude. Quite the contrary, if you want to help designers and programmers work effectively together in this manner give us something that works with tools we already know and possess. We're not afraid of learning a new system, just help it be somewhat familiar. Macromedia has a similar approach when they designed Dreamweaver's UI to be similar to Photoshop.
Seems your users agree in this recent forum post
My $.03 |
|
Back to top |
|
avenger Smarty n00b
Joined: 12 Feb 2004 Posts: 1
|
|
Back to top |
|
gjmacd Smarty Rookie
Joined: 25 Oct 2003 Posts: 13 Location: Boston
|
Posted: Fri Mar 05, 2004 7:33 pm Post subject: XLST is not good for presentation |
|
|
Zoran wrote: | The only true alternative to the templates is xml/xsl/xslt but... that is another story.
I think that his article is interesting but I would never use his template class instead of smarty. It looks like comparing a parachute with space ship Enterprise.
P.S. http://www.sitepoint.com/print/1218 this print form of article is much more user friendly and without adds |
No. I disagree. I think XSLT is HORRIBLE for building GUI interfaces.
Case and point:
in XSLT to display a table, you'd have to create the following syntax:
<xsl:element name='table'>
<xsl:element name='tr'>
<xsl:element name='td'>
</xsl:element>
</xsl:element>
</xsl:element>
Very verbose to just do a table.
Also, debugging is HORRIBLE. A simple syntax problem, because of the interim XSLT file, can take a long time to solve. Not to mention the ability to have it all go to hell if someone uses an international character in the XML....
Another problem:
Natively on most hosting locations XSLT is NOT included in PHP -- the sablotron engine is not compiled in. Thats a problem for PHP folks.
MS folks have it easier, as its built right into IIS -- but then your talking windows.
Personally, and philisophically, I think building a GUI and using XSLT, XML etc. is a bad choice and you tend to have layers of complexity that you shouldn't have to deal with when you want to maintain a GUI.
Sure, you could go and use some application server to make it easier, but then thats yet another layer of complexity, or you could have a big ass wrapper that makes the templating in XSLT easier for GUI's -- but its still a performance hog when you have to start up a parser.... Smarty, or any PHP template engine for that matter is far easier in the grand scheme of things.
XSLT is a great language for manipulating XML. Taking it and shaping it for something else. But its terrible for using it as a presentation layer.
IMHO. |
|
Back to top |
|
fbronx Smarty Rookie
Joined: 28 May 2003 Posts: 11 Location: Stekene, Belgium
|
Posted: Mon Mar 15, 2004 10:28 am Post subject: Re: XLST is not good for presentation |
|
|
[quote="gjmacd"] Zoran wrote: | in XSLT to display a table, you'd have to create the following syntax:
<xsl:element name='table'>
<xsl:element name='tr'>
<xsl:element name='td'>
</xsl:element>
</xsl:element>
</xsl:element>
Very verbose to just do a table.
|
You don't have to use the xsl:element for this. Just mix XHTML and XSLT-tags like this:
Code: | <?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html" indent="yes" />
<xsl:template match="/items" >
<html>
<body >
<table border="1">
<xsl:apply-templates />
</table>
</body>
</html>
</xsl:template>
<xsl:template match="item" >
<tr>
<td><xsl:value-of select="@desc" /></td>
</tr>
</xsl:template>
</xsl:stylesheet> |
|
|
Back to top |
|
Pineapple Smarty n00b
Joined: 23 May 2003 Posts: 3
|
Posted: Fri May 14, 2004 10:44 pm Post subject: Re: Beyond the template engine |
|
|
What overhead? It's amazing how many people overlook that Smarty compiles the templates into PHP. There is no parsing done once the template is compiled. |
|
Back to top |
|
electr0n Smarty Rookie
Joined: 26 Mar 2004 Posts: 32 Location: Germany
|
Posted: Sat May 15, 2004 12:11 pm Post subject: Re: Beyond the template engine |
|
|
zbiru wrote: |
There is also very interesting Savant Template System for PHP (http://phpsavant.com/). Like mentioned in articles above, it also uses PHP itself as its template language so you don't need to learn a new markup system. It has an object-oriented system of template plugins and output filters, so it supports almost all of the power of Smarty with almost none of the overhead. |
Savant is a very bad solution. I tested it for a while and it doesn't seperates php(logic) from layout(html). If you don't believe me look at their website. |
|
Back to top |
|
BRDude Smarty Rookie
Joined: 23 Nov 2003 Posts: 17
|
Posted: Wed Jun 09, 2004 10:46 am Post subject: Re: Beyond the template engine |
|
|
electr0n wrote: | Savant is a very bad solution. I tested it for a while and it doesn't seperates php(logic) from layout(html). If you don't believe me look at their website. |
It's true that Savant does not separate php from html, and that's not the purpose behind it. Like many template engines, the purpose is to separate business logic from display logic and Savant acomplishes just that with minimal overhead by limiting itself to using plain PHP.
I think it all comes down to the discipline of the programmer. Even when using Smarty, I've made mistakes like adding business logic in templates and display logic in PHP code (even though Smarty provides all the tools to separate them). The boundaries are not clear for some people or in some situations, but we can all agree that the distinction exists, it's all about discipline.
btw, the URL you mentioned in the Savant website is a perfect example of business/display logic separation, I might be wrong but I didn't see any problem there, perhaps you could point it out. |
|
Back to top |
|
|