The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

It actually would be more server load even though it would be minimal b/c when you use a template engine such as Smarty there is more parsing going on b/c it parses the new syntax into the real syntax thus adding another layer of parsing.

It actually would be more server load even though it would be minimal b/c when you use a template engine such as Smarty there is more parsing going on b/c it parses the new syntax into the real syntax thus adding another layer of parsing.

It parses the template once, and then all requests use the compiled version, only re-parsing if you change the template. The overhead is negligible; at the least, it isn't a valid reason not to use it.

It actually would be more server load even though it would be minimal b/c when you use a template engine such as Smarty there is more parsing going on b/c it parses the new syntax into the real syntax thus adding another layer of parsing.

The fact that it needs caching in the first place to claw back some performance should tell you something about how much more bloated it makes your applications...

server load

Originally Posted by kyberfabrikken

Such polls are rarely very useful. I'm pretty sure, you would get a number of votes for both solutions.

till now i couldn't find truth in any poll.

to come back to the higher server load argument. No, this is not a very good argument against smarty if its concept would have advantages. But as mentioned before, there are other, better, arguments to use php as template engine. We can pay good concepts with higher server load but this isnt an issue here.

Given the sample code from the post before yours, the smarty code basically looks like PHP functionality, but rewritten to something different. Are you telling me that rewriting a language to achieve nothing at all (after all, the whole point is to separate the logic, and it actually just has exactly the same logic in a different format) isn't excess bloat?

That code example also puts to rest the 'designers cant use programming languages' argument. If they understand the concepts of one, all that you need for the other is a knowledge of the syntax.

Smarty is burden for personal developers. If you're just a single developer and developing custom applications which you will sell to just 1 or 2 clients then according to me you should make your own arrangements so its easy for you in the longer run.

If you're a team for a big project or a business project in which the design will keep on changing and programmers/designers will keep on changing then use standard stuff like Smarty etc. so new people who come aboard can easily adapt the to the project and start giving output asap.

Its really just to save time and money. Its you who has to decide which way you have to do it - really. Oh personally i like phpbb's template engine atleast in that we don't have to learn another language. For eg. they do loops like this in template:

Given the sample code from the post before yours, the smarty code basically looks like PHP functionality, but rewritten to something different. Are you telling me that rewriting a language to achieve nothing at all (after all, the whole point is to separate the logic, and it actually just has exactly the same logic in a different format) isn't excess bloat?

That code example also puts to rest the 'designers cant use programming languages' argument. If they understand the concepts of one, all that you need for the other is a knowledge of the syntax.

That example is actually rather complex and not something I would give our designer to work with. Smarty has a lot of language constructs that I don't find use for. Loops and if constructs are almost unavoidable, there is a lot of other functionality which isn't entirely necessary for templating. I occasionally will create complex data driven markup myself and feed it to a smarty variable rather than represent it in template language. It may break the rules somewhat, but I don't care.

We have to deal with a lot more rules than what a tag based system like Smarty imposes. Curly braces, function arguments, ending lines with semi-colons. Smarty has if and endif and similar simpler rules. If you were forced to do an application with just what Smarty provides, you would be pretty frustrated. It's simply not the same thing.

We are talking about PHP, but what about designers that come from ASP, Cold Fusion or Ruby shops. Are they expected to learn all those disciplines just so they can work with the back end people? On who's dime do they learn?

Don't let your perspective as a programmer make you think that everyone has the same aptitude in the same areas as you (a stock broker isn't stupid because he isn't computer literate although there is a limit to that concept), or forget what you or others may have gone through to develop the knowledge that you have.

Given the sample code from the post before yours, the smarty code basically looks like PHP functionality, but rewritten to something different. Are you telling me that rewriting a language to achieve nothing at all (after all, the whole point is to separate the logic, and it actually just has exactly the same logic in a different format) isn't excess bloat?

The smarty version is 1/4 of the size, and does some basic type checking you don't get if you simply did a foreach in PHP. Even the most trivial example:

Code:

{$data->id}
vd
<?php print $data->id ?>

The smarty version is half the size, which might not seem like much, but on a big page it makes a real difference. And that, to me, is the basic problem with using pure php; the syntax is bloated, which leads to templates being hard to read and maintain, and using a template language can help with this tremendously.

The smarty version is 1/4 of the size, and does some basic type checking you don't get if you simply did a foreach in PHP. Even the most trivial example:

Code:

{$data->id}
vd
<?php print $data->id ?>

The smarty version is half the size, which might not seem like much, but on a big page it makes a real difference. And that, to me, is the basic problem with using pure php; the syntax is bloated, which leads to templates being hard to read and maintain, and using a template language can help with this tremendously.

If you wrote the php template like that, then yes, it saves time. Luckily I don't. I have functions to check and validate data much earlier on (as im sure you do when using smarty as well), then just use a simple foreach loop.

Given the sample code from the post before yours, the smarty code basically looks like PHP functionality, but rewritten to something different. Are you telling me that rewriting a language to achieve nothing at all (after all, the whole point is to separate the logic, and it actually just has exactly the same logic in a different format) isn't excess bloat?

The example you make reference to isn't a particularly good example of how to use a template engine.

In my mind the qualities of a good template engine are:

No PHP allowed in templates for security and ensure consistency in their use.

No silly braces to represent anything beyond simply echoing out a value.

Use XML style tags embedded in the html which makes calls to a registered view helper class.

The above example is actually pretty good code, and it's simple to understand by PHP developers. However, you wouldn't want to use the PHP method if you have concerns about security (this should be a concern where untrusted parties may have access to the templates), or if you want to ensure consistency so that some developer you hired two weeks ago doesn't stick an SQL query in the middle of your template.

If the issues mentioned above are not problems for you, then a PHP based view may be all you need. However, if you do have concerns about security or consistency, then don't discount a template engine.

When you have a middle/major sized project, with lots of people involved, a template-engine is the right way to go, fmpov. It will definitly safe you some time. Libraries like Smarty are stable, good documented and you can get lots of usage examples. Not said, that this would not be possible with going the html+php route, but.. when you rely on a library your options in the "view" are some kind of restricted to the expression-possibilites of the library itself. And on projects with many people involved, such standards are highly recommended.

You could say they do it all wrong - but, another fact is, that a big bunch of major web-applications are template-engine driven. Be it Smarty, Joomla's patTemplate or Drupal's phptal.

If you wrote the php template like that, then yes, it saves time. Luckily I don't. I have functions to check and validate data much earlier on (as im sure you do when using smarty as well), then just use a simple foreach loop.

That was an extreme example, but my point is that even in the simplest cases, the syntax of a smarty or another templating engine will be shorter than the pure php version, which makes the template version easier to read. It is a trade off, though, and on small projects where I'm the sole developer I don't bother; but on big projects with multiple developers, a templating engine can make life easier.

The above example is actually pretty good code, and it's simple to understand by PHP developers. However, you wouldn't want to use the PHP method if you have concerns about security (this should be a concern where untrusted parties may have access to the templates), or if you want to ensure consistency so that some developer you hired two weeks ago doesn't stick an SQL query in the middle of your template.

If the issues mentioned above are not problems for you, then a PHP based view may be all you need. However, if you do have concerns about security or consistency, then don't discount a template engine.

What I often do is assign everything (or near everything) to a variable, much like in a templating system. But instead of assigning it to a member of a tpl_var array, I just throw it all in the global scope and include the template.

I'm sure tons of people are against the whole global concept, and I'm sure you could do things more elegantly, but I've found it to be the simplest, easiest method. It's also quite reminiscent of a template engine. Just with cooler syntax.

Originally Posted by BerislavLopac

<?= is even shorter. I know that it may not be universal, but it's quite good enough for my purposes. And if necessary it can be transformed to <?php echo with a simple search and replace.

Yeah, I know, but I've been brainwashed into the anti–short tags cause.

Originally Posted by 33degrees

That was an extreme example, but my point is that even in the simplest cases, the syntax of a smarty or another templating engine will be shorter than the pure php version, which makes the template version easier to read.

Short doesn't necessarily mean easier to read. I personally find PHP easier to read than Smarty (perhaps because I'm more familiar with PHP). Regardless, I still think "foreach posts as post" is easier to read than "foreach from equals posts item equals post."