Smarty Forum Index Smarty
The discussions here are for Smarty, a template engine for the PHP programming language.

The Logic of Templates (massassi.com)
Goto page Previous  1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic    Smarty Forum Index -> Article Discussions
View previous topic :: View next topic  
Author Message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7367
Location: Lincoln Nebraska, USA

PostPosted: Tue Apr 29, 2003 2:29 pm    Post subject: Reply with quote

Quote:

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 Smile


I'd like to see your tests.

Those are some old benchmarks, but yes look at them! You will see how the comparisons begin excel in anything more than a "hello world" type of benchmark (look at the last couple). I admit Smarty has a simplicity threshold, so I agree if your app is just a simple "hello world" then don't use Smarty. But anything close to a real situation and you'll start seeing the performance gains over other solutions.

I guess it depends on what and how you are testing. Using an accelerator or not, benchmarking through the webserver or command line, etc. Its tough to get comparisons that mean much of anything.

Monte


Last edited by mohrt on Wed Apr 30, 2003 2:32 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
Brian
Smarty Rookie


Joined: 29 Apr 2003
Posts: 21

PostPosted: Tue Apr 29, 2003 5:15 pm    Post subject: Reply with quote

Well, I don't see your benchmarks on the site anymore (they used to be at phpinsider.com or something). Regardless, there's nothing you can [programmatically] do with Smarty that you can't do with a native php solution as I presented in that article. What you can do is force the template designers to only use pre-defined functions (plugins, modifiers, filters, etc.), remove access to certain things (db passwords, db connections, php functions, etc.), and force a structure that isn't there otherwise. However, with well-behaved designers, this is also possible with a native php solution. And you get the same result (separate presentation logic from application logic).

The benefits are speed (don't load the huge base classes + the dozens of modifiers/plugins/etc.), simplicity (you're not running template files through huge, difficult to understand regexes [which are important to understand if you want to extend the smarty syntax]), and a more well-known and well-documented syntax (php itself).

So in short (honestly I think we're in agreement, rather than arguing here):

benefits of native php solution:
faster
more powerful (can use any php functions w/out having to write modifiers/plugins/etc. [and disable {php} to acheive the security model discussed below])
less file access (no need for dozens of separate plugin files)
easier to debug (debatable)
no need for special {literal} tags around js and other "special" things that screw up smarty's parser
easier to extend
doesn't require an accellerator to be fast (most people are hosted remotely and don't have access to install things like that on the server) - and a buggy accellerator at that - we use phpa here at work and we have run into object inheritance issues that disappear when the accellerator is turned off

negatives of native php solution:
harder to understand syntax (debatable - esp. after eliminating $this->get())
no security model (in the implementation I discussed)
no pre-built plugin library (can be remedied easily)
no tight coupling of different technologies (config files, whatever else smarty provides)

equal between the two:
support for things like conf files (can easily d/l a class to handle this)
caching (I can post the code for the one I wrote when I'm not at work)

Obviously these are all opinions. We can argue till we're blue in the face but nobody is going to convince me that the smarty foreach syntax is "better" than the native php one. And I'm not going to convince you. But thanks for the feedback on the article Smile I didn't mean to make it into a flame war (and in fact, I recall stating that smarty is closest to my "ideal" template system than any other solution (including the one I wrote - bTemplate).[/list]
Back to top
View user's profile Send private message Send e-mail
Brian
Smarty Rookie


Joined: 29 Apr 2003
Posts: 21

PostPosted: Tue Apr 29, 2003 5:17 pm    Post subject: Reply with quote

Since I didn't find your benchmarks, here are the ones running on my server that I put up when bTemplate came out:

[removed - my server is choking for some reason and all the benchmarks are something like 8000 seconds - I'll repost when things are back to normal]

Maybe someday soon I'll put the native php solution in there and see how it compares. But I'm now coding php 9.5 hrs a day (8 @ work & 1.5 during my commute) so it gets a little annoying going home and messing with it again Sad
Back to top
View user's profile Send private message Send e-mail
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7367
Location: Lincoln Nebraska, USA

PostPosted: Tue Apr 29, 2003 5:48 pm    Post subject: Reply with quote

Just to clarify, plugins are only loaded on demand, so there is no overhead of having even hundreds of plugins in your Smarty installation.

Sure you can do anything in PHP that is done in Smarty, heck it's written in PHP. You can also write anything in assembly that can be done with C++, but there comes a point where assembly just isn't practical.

Smarty supplies a lot of features that would otherwise need to be built around simpler template engines, so directly comparing them may not be conclusive.

Monte
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Tue Apr 29, 2003 10:04 pm    Post subject: Reply with quote

I don't know if these are the benchmarks that you are looking for, but anyhow:

http://smarty.php.net/contribs/benchmark/smarty_phpa_benchmark.tar.gz
Back to top
View user's profile Send private message
andre
Smarty Pro


Joined: 23 Apr 2003
Posts: 164
Location: Karlsruhe, Germany

PostPosted: Wed Apr 30, 2003 7:46 am    Post subject: Reply with quote

mohrt wrote:
Smarty supplies a lot of features that would otherwise need to be built around simpler template engines, so directly comparing them may not be conclusive.


Sometimes I am really missing some features in PHP which Smarty provides Wink Smarty makes (fast) developing so nice and easy. If I remember one year ago I used FastTemplates ... I hated displaying a list of entries as a table with cycling row colors. I needed two templates: One for the table header and footer and one for a table row. Then make a loop in PHP with $color = ($color == "red")?"green":"red", loading template, assign each row value, copy content in string... etc. etc. etc. ...

Now it's just a simple section ... not more than a few lines. Smarty just makes fun to use... Very Happy
Back to top
View user's profile Send private message
minorgod
Smarty Rookie


Joined: 30 Apr 2003
Posts: 6

PostPosted: Wed Apr 30, 2003 6:30 pm    Post subject: missing the point... Reply with quote

It seems like some people here have missed the point of the article. The fact of the matter is, SMARTY and other advanced template engines quickly get to the point that the syntax is as complex, if not more complex than the PHP functionality it provides access to. In the end, having a syntax such as {$variable} does not make it ANY easier for template designers. In fact, if the template designer has to do much work with JavaScript, which is often the case, then it will really piss him off because he will have to put {literal} tags around every single curly brace. What does that simplify? Combine that with the fact that NO visual editors support smarty tags without modifying config files, whereas Dreamweaver has no trouble displaying even the ugliest PHP code inline with the page layout, provided you're not printing your HTML content directly from php scripts via echo or print statements. So if you're talking about templates being easier for Visual HTML designers to use, then you're high. If visual HTML designers CAN use smarty, they must know how to do at least a bit of coding. Smarty simply adds another complex syntax into the mix. I love many of SMARTY's features, but I have no clue why anyone would say that {$variable} syntax is easier to deal with than <? $variable ?> syntax when the latter is the only one interpreted gracefully by any visual editors. I myself am knee deep in a project where I have to use PHP to spit out dynamic JavaScript functions into a template which finishes building the JavaScript functions. This is mind-numbing work when mixing 3 syntaxes on the same HTML page and being forced to wrap some if it in special tags so one language doesn't trample all over the other. The fact is, that there is no such thing as a visual HTML designer anyway. If you design HTML pages, then you are a coder. If not, then you're a graphic designer who is swimming in the deep end and should either take the few hours to learn more or stick to print design. If you can understand SMARTY you could easily understand any template language that uses PHP style syntax. We're talking about opening and closing tags for god's sake. Every other aspect of SMARTY could be duplicated in equally simple PHP syntax by writing the appropriate functions in the template engine. Taking visual editors into account, dealing with PHP tags is actually much easier than dealing with curly braces which already have decades-long-established contexts within the programming community. {$variable} syntax is the one really stupid thing about SMARTY.
_________________
Nowhere does science promise emancipation.
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7367
Location: Lincoln Nebraska, USA

PostPosted: Wed Apr 30, 2003 6:58 pm    Post subject: Re: missing the point... Reply with quote

Quote:
because he will have to put {literal} tags around every single curly brace.


Just an FYI, you should put one set of {literal} tags around your entire javascript section, not around every curly brace. If you need Smarty tags embedded in the javascript, then use {ldelim} and {rdelim} in place of the javascript curly braces.

Another option, change your default delimiters to something both editor and javascript friendly.

Monte
Back to top
View user's profile Send private message Visit poster's website
minorgod
Smarty Rookie


Joined: 30 Apr 2003
Posts: 6

PostPosted: Wed Apr 30, 2003 8:26 pm    Post subject: Reply with quote

Gosh that REALLY simplifies things (sarcasm). Changing the default delimiters for javascript? Not possible (that I'm aware of). And changing the default delimiters for PHP? To accomodate SMARTY? I think not. Besides, this is not an option for designers who don't happen to have access to their php.ini file (or can that be set in an .htacces directive?)Your comments are valid, but they don't enhance the arguement for SMARTY making life easier for designers OR programmers. PHP+SMARTY = 3xharder than PHP alone, at least from a programmer's standpoint. And I'd much rather waste a designer's time than a programmer's time. That's just economics. I've written entire PHP applications from scratch in the time it takes to decipher and modify one small part of our template-based e-commerce application. Nightmare on Smarty Street. Love smarty, hate the syntax. Take the regex_replace modifier for example. To do this in SMARTY you say {$variablename|regex_replace:"/pattern/":"replacement"}

in php you say:

<? preg_replace("replacement","/pattern/",$variablename) ?>

The syntax is much more straighforward in PHP and you have the added benefit of being able to easily concatenate variables into the replacement. I've yet to find a solution for this in smarty. Like how would you use a variable such as $smarty.section.mysection.index within a smarty regex_replace? Answer, use {php} tags and do it in PHP from within the template. So many of the SMARTY modifiers are simply wrappers for identical PHP functions, yet they reverse the order of the function arguements half the time. This means that both the programmer and the designer get to learn new syntax to do the same preg_replace via a PHP wrapper function. Oh joy! Why not save the programmers some headache and just have the designer spend the few hours it would take them to learn the rudiments of PHP. I'm not trying to bash the concept of templates or even Smarty in particular, I'm just saying there's some things about it that don't make sense. When you're just creating a wrapper function for a PHP function, at least leave the friggin function arguements in the same order so programmers who already understand the underlying functions don't have to forget all the programming conventions they've been using for years just to make the same function call a different way with another abstraction layer in between.
_________________
Nowhere does science promise emancipation.
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7367
Location: Lincoln Nebraska, USA

PostPosted: Wed Apr 30, 2003 9:02 pm    Post subject: Reply with quote

minorgod wrote:
Gosh that REALLY simplifies things (sarcasm). Changing the default delimiters for javascript? Not possible (that I'm aware of). And changing the default delimiters for PHP? To accomodate SMARTY?


I mean change the default delimiters for Smarty. I thought that was obvious since its really the only feasible choice.

Quote:
Take the regex_replace modifier for example.


Most of this complexity you refer to should be done in PHP before being assigned to the template. If it were my choice, I'd remove regex_replace altogether because it suggests doing things like this that should never be done in templates. But I'm not the sole decision maker, everyone has an input. regex_replace is nice in a pinch for a quick fix, but really think about what you're doing, it can usually be done (and should be done) in PHP before var assignment begins.

Smarty is a double-edged sword. It provides a lot of power to the designer, it does take discipline to make things right: keep the templates as simple as possible and focused on presentation. Do everything else in PHP. If you have to mangle your vars with a bunch of regex's and catenation in the template, then maybe you should rethink how those vars are assigned in the first place.

Monte
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Thu May 01, 2003 4:50 am    Post subject: Reply with quote

Quote:
{$variable} syntax is the one really stupid thing about SMARTY.


minorgod, if that's all that Smarty did, not one of us would be using it. But we do use it which means it is doing more than syntax swapping. Certainly you are not accusing anyone of not being able to write their own regex's, right Wink? But lets look at the syntax issue again, since it seems to (incorrectly) drive the fuel against Smarty.

First, your reasoning leaves a bit to be desired. PHP uses $ variable syntax while javascript does not. Shouldn't that get the designers squeezing the same grapes?

Second, I think you meant <?=$var ?>and not <? $var ?>. The latter syntax does not work. You can also forget the first syntax altogether if your php has short tags off. Many servers do not support short tags, nor should they because it blows up a common document standard. PHP officially suggests that you use <?php. That means you have to do things like <?php echo $var ?>. Also, all of these PHP code examples use the little trick of NOT ending the final statement in a PHP block with a ";". Its not even syntax compliant PHP. Smarty solves this problem once and for all and with a pragmatic syntax. As I've pointed out previously, Smarty provides several other syntax niceties in addition to this first one that makes template syntax simple to write, read and understand.

Third, you mentioned several times that designers must become programmers to be useful. So you say. I say that designers need (and WANT) to know as little as is required to get their DESIGN JOB done. Ask them. Then ask them which is easier, inserting javascript or inserting Smarty. When I think about it, shouldn't your programmers be writing the scripts? At most, the designers are injecting snippets from a library. Besides, I'm sure you know that a good application framework will handle Javascript silently. (...also, Smarty makes it easy to hide Javascript details, like it does with the popup plugin).

Fourth, perhaps you are unaware that many visual environments can support Smarty. Many programmer IDEs (even jEdit) do as well. They may require some small config--but my gosh, are designers suddenly too stupid to be able to config their own tools? You can't have it both ways, that they need to be programmers but can't use their own tools. In most organizations, there are people available to do that, anyhow. If you are working on your own from home, then you must know how to use your own tools.

FINALLY, I agree with you that there can be MORE DONE to support the developer in terms of Smarty. A standardized data component and a proper pipeline, me thinks. As it is, I think your comment on the economics of the situation is very unfair. There is not THAT much work that needs be done and it is usually a one-time, upfront affair as opposed to the ongoing designer needs. Also, it is often possible to extend / change your site within template WITHOUT going back to the programming staff.

EDIT:

ps. I'm not against using PHP for templating--I just don't think that because PHP can do templating that it means Smarty is superfluous or worse, useless. On the contrary--with Smarty, "templating" is just the getting the toe wet part. Its the part that enables all of the other neat features it provides.

Yes, PHP can do all those things that Smarty can (of course, Smarty is programmed in PHP and it compiles scripts INTO PHP) -- but only after you design, code and test it yourself.
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Thu May 01, 2003 8:52 pm    Post subject: Reply with quote

Here's another article that takes the massassi argument:

http://www.phppatterns.com/index.php/article/articleview/4/1/1/
Back to top
View user's profile Send private message
Brian
Smarty Rookie


Joined: 29 Apr 2003
Posts: 21

PostPosted: Thu May 01, 2003 10:09 pm    Post subject: Reply with quote

boots wrote:
Here's another article that takes the massassi argument:

http://www.phppatterns.com/index.php/article/articleview/4/1/1/


It's a bit different. The "massassi" argument still uses a "template engine" and separates the display logic elsewhere. This is sort of similar to phppatterns, but those guys are embedding a ton of html/css directly in their php pages. That sucks, because you can't just define a new template and have a different output format (xml, plain text, csv, etc.). At least, that's what they advocate later in the article...
Back to top
View user's profile Send private message Send e-mail
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Sat May 03, 2003 1:07 am    Post subject: Reply with quote

Brian wrote:
It's a bit different. The "massassi" argument still uses a "template engine" and separates the display logic elsewhere. This is sort of similar to phppatterns, but those guys are embedding a ton of html/css directly in their php pages. That sucks, because you can't just define a new template and have a different output format (xml, plain text, csv, etc.). At least, that's what they advocate later in the article...


Also proves the need for Smarty. Smarty solves a problem that some, ahem, will not be able to properly solve. It solves this problem in a consistent way that is accessible to a large class of users--both at the API and Template level.

I posted this link to show the other side of PHP as template solutions. Smarty transparently solves many problems that I have to deal with as an application developer.
Back to top
View user's profile Send private message
Wom.bat
Smarty Pro


Joined: 24 Apr 2003
Posts: 107
Location: Munich, Germany

PostPosted: Sat May 03, 2003 10:07 am    Post subject: Reply with quote

If you ask me, all those people out there who are whining about Smarty being too heavy/overkilled/feature-rich/slow etc. didn't get the purpose of it. With the average "replace-this-%foobar%"-template-"engine", you are far away from having a seperation of application and presentation logic. They have to format their dates and times in their PHP code, they have some PHP code which splits an array into two so that they can have two columns of data on their page, they do ugly things with variables like "if-colnum-div-two-is-zero-then-make-it-green-otherwise-make-it-red" and use them with css etc.
Brian is damn right, this sucks, and those people are real dilettantes if they even want to sell their way of producing bad results to other people by telling them it's the best and only one.
You _can_ have such things within your PHP code, but then you need a clean MVC, and IMHO that's not the very right thing for PHP applications.
I know I have said this already a hundred times, but Smarty is the only serious way of cleanly keeping application and presentation logic apart.
Sure, you can do the pure way by having templates with pure PHP code, too, but Smarty is way faster with things like {$var|truncate:50:"...":false}
In my applications, I usually assign only one or two variables to the templates: one containing the payload, and, if needed, one containing information I need in the template... that's all... Smile
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Smarty Forum Index -> Article Discussions All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 2 of 6

 
Jump to:  
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
Protected by Anti-Spam ACP