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.

I've used Smarty and pears html_template_it. Smarty has a lot of very useful features but does involve using some logic (loops etc). Pears html_template_it does a better job of extracting logic from structure and uses a notion of blocks to create iterable chunks of code.

Smarty has the best features and is probably faster due to it's template caching system but html_template_it is much more simple and more elegant.

Agreed. Don't use a templating engine, they don't actually achieve anything. Just use php.

Have you ever used a templating engine?

To say they "don't actually achieve anything" is inane. They definitely achieve something - a separation of presentation and logic.

With a templating engine, your script must pass all of its 'content' information created through logic functions to the templating engine. The designer can then take the raw information and fill out the presentation aspect of the page with html and the content values.

It might be a valid argument to say they are inefficient or redundant, but they definitely accomplish something. They increase the abstraction of an application, so that each task in the whole project can be done independent of the other.

To say that they do nothing is like saying that abstracting your applications into classes "does nothing." It may not be necessary, and it may be argue-able when they are appropriate... but they definitely serve a legitimate purpose.

One doesn't need a template engine to seperate presentation from logic. Template engines are generally used when there is a nerd developing the back end and a arty designer coding the front end.. Smarty makes it easier on the designer by trimming down the geeky code as much as possible. Short tags were supposed to do the same thing.

To say they "don't actually achieve anything" is inane. They definitely achieve something - a separation of presentation and logic.

Not really, all they do is place the same information 1 step further away. I have used templating engines extensively, at work, and they don't do anything like this. Just because you put the html inside a page with php, doesn't mean suddenly all your business logic is there. You still keep the business logic in the classes and helper functions, and the php that displays the page just simply makes use of those.

So no, a templating engine doesn't separate presentation and logic at all, that can easily be done with php too.

Also, as wonshikee pointed out, there is usually just as much logic in a template as there is in php anyway. You HAVE to put logic in a template, it is completely impossible to separate them entirely.

So no, a templating engine doesn't separate presentation and logic at all, that can easily be done with php too.

You just refuted your own point. You said, "that can easily be done with php too."

Like I said, it can be debatable whether or not a templating engine is efficient. To some people, it may not be worth the extra level of abstraction.

However they clearly achieve a goal. That goal may be achievable with PHP as well, but that doesn't mean that a templating engine doesn't achieve that goal.

My point isn't that PHP can't be used as a solution, or that templating engines are the best solution. They are, however, a viable solution. It may be arguable whether or not they are efficient, but to say they do nothing is inane.

Okay...then they do nothing of great worth. There drawback out weigh the pros of using another layer of abstraction.

I've been working with PHP for years now and for the beginning part of those years I used a templating engine. So yes I do know what I am talking about and templating engines just add more crud and confusion to the mix, just one more thing to keep track of and to learn.

Logic without the fatal effects.
All code snippets are licensed under WTFPL.

You just refuted your own point. You said, "that can easily be done with php too."

I haven't refuted anything. If it can be done with either, why on earth would you add an extra layer of bloat to the software that it just doesn't need? I don't think templating engines abstract anything, they just move the same abstraction 1 layer further away. Just because you have another layer for something that SEEMS to do something different, doesn't mean it actually DOES anything different, and doesn't mean it is any more abstracted than before. It just wastes CPU cycles and increases loading time for no gain.

I can't agree that a templating engine 'doesn't do anything'....when i look at a templated php file, without all the structual html in there things are so much easier to work with......and things are'nt always quite as drastic as wonshikee suggested.

Okay...then they do nothing of great worth. There drawback out weigh the pros of using another layer of abstraction.

Fair enough. There's an argument that makes some valid points.

For the record, I wasn't trying to imply that you don't know what you're talking about. The comment about never using a templating engine was directed at the other poster that said flat-out that templating engines don't do anything.

Agreed. Don't use a templating engine, they don't actually achieve anything. Just use php.

That's incorrect. Templating engines like Smarty serve the purpose of keeping PHP out of your templates which serves three specific goals.

1. Security. By keeping the templates free of potentially damaging PHP it becomes safe to allow untrusted parties to edit or create their own templates/themes.

2. Usability. By restricting templates to a series of simple commands (and not trying to re-invent various PHP constructs as Smarty does) the templates can be made easy to use for people unaccustomed to programming such as designers.

3. Consistency. By enforcing a particular interface for template development you can ensure that templates are developed in a consistent manner, avoiding the temptation of using quick hacks to resolve problems, something that's always a concern when developing in a team.

That's incorrect. Templating engines like Smarty serve the purpose of keeping PHP out of your templates which serves three specific goals.

1. Security. By keeping the templates free of potentially damaging PHP it becomes safe to allow untrusted parties to edit or create their own templates/themes.

It is just as easy to cause a problem with a template as it is with php - it does have the logic in after all. I don't think it adds any more security than normal.

Originally Posted by Richard Bone

2. Usability. By restricting templates to a series of simple commands (and not trying to re-invent various PHP constructs as Smarty does) the templates can be made easy to use for people unaccustomed to programming such as designers.

Most designers aren't as incompetent as you make them out to be :P The problem can easily be solved by hiring designers who are willing to learn new things / aren't idiots. Using PHP really isn't that big a step from a smarty template, just a different syntax.

Originally Posted by Richard Bone

3. Consistency. By enforcing a particular interface for template development you can ensure that templates are developed in a consistent manner, avoiding the temptation of using quick hacks to resolve problems, something that's always a concern when developing in a team.

I have never found that 'not using a template' equates to 'willing to use small hacks' - I don't see the logic here? It is just as easy to develop consistently with php.

What I HAVE found though, is that using templates means the php behind the view is usually quite untidy - people think it doesn't matter how it looks because they are under the impression that it is abstracted away from you. I have seen this several times.

It is just as easy to cause a problem with a template as it is with php - it does have the logic in after all. I don't think it adds any more security than normal.

I tend to disagree. Unless you're going to completely disable all potentially damaging operations (file system access and database access minimum) when you reach your templates, PHP will always be a much higher security risk in the hands of untrusted parties.

Originally Posted by Stormrider

Most designers aren't as incompetent as you make them out to be :P The problem can easily be solved by hiring designers who are willing to learn new things / aren't idiots. Using PHP really isn't that big a step from a smarty template, just a different syntax.

I think that largely depends on how we're talking about using your template engine.

If you're going to take the Smarty route and use its reinvented PHP syntax then I'd agree with you. However I tend to think that's a pretty poor example of a template engine. What I like to use is more like the following:

No messy if statements, just xml tags with a well defined purpose that can easily be understood at a glance.

Originally Posted by Stormrider

I have never found that 'not using a template' equates to 'willing to use small hacks' - I don't see the logic here? It is just as easy to develop consistently with php.

As a lone developer I'd agree with you; but consider a team working together. While you'd always hope that all would adhere to the proper standards, in reality that's not always going to be the case. Sometimes you'll hire new people who inevitably aren't familiar with your standards, or a developer might be running behind schedule and cut corners with the soothing promises of that devil on their shoulder telling them they'll clean that up later.

It reads pretty much like English, easy to understand what is going on!

I just don't see the point in moving all your html out of where it was, putting placeholders for data, then moving all the data into the placeholders and bringing the html back. Seems like a complete waste of effort to me, and I see no advantage to it - both at work and developing things by myself.