Template Engine or HTML with embedded PHP?

[OneSeventeen]

My project will basically have a core class to handle all script loading and display, with a few extra classes tied in for authentication and database connectivity. (I love abstraction, so we can migrate to a different platform in a matter of hours rather than days.)

I'm basically doing a script management system (or as I prefer to inaccurately label it: "Content Management System Management System")

Instead of loading content, it loads web applications, but those applications have default attributes such as "go live" dates, expiration dates, and group-based permissions.

[bradical1379]

I'm with the 'use PHP with HTML' crowd here. Template engines are unnecessary bloat.

Wouldn't code bloat be embedding client-side code in your server-side code?

[Stormrider]

Er, no. That is nothing to do with bloat, and considering that it is the server code that generates the client code, they are related to each other anyway. You cannot completely separate them. I still keep all my business logic in classes away from the presentation, then use the API provided by the classes to echo content out to the presentation layer, mixed with static HTML when required.

[dvduval]

Since we started using Smarty in phpLD I have never looked back once. I think it does a great job of separating code from design. If all he is doing is writing a pretty simple PHP application that serves a small audience, I am not so sure the extra work is needed, and may delay getting it up and running. If his concern is making something that will stand the test of time, and allows for many different people to work on the code and design, I think Smarty would be the smartest choice.

[chestertondevelopment]

To those claiming that PHP developers should make the designer use Smarty or else sack them, I wonder if you've ever actually been part of a real business or project.

It's not an option just to get rid of a good designer because they can't/won't learn PHP syntax. Projects have deadlines, try explaining to management why you made someone take an extra couple of days to learn PHP syntax over Smarty syntax, the output is the same in the end.

In the real world, there are compromises, I used to be in the camp of 'smarty is evil, pure PHP templates are the way to go' but I realize that is naive, in a perfect world everyone will use PHP templates but the world isn't perfect and Smarty isn't all that bad anyway.

[Hammer65]

I agree. Especially if you are not the boss, it isn't your place to demand that an otherwise good designer learn your way of doing things. If you are an indy, fine do it whatever way feels good to you. As i said before, the place I work for has a lot of CMS installs that are developed and then released to the client. None of those clients have a web team. They have someone who knows little or nothing about HTML update the site. This is unique to CMS systems. As the OP mentioned a CMS, I really think that a templating system is the best choice.

Any performance penalty there is in using Smarty is not that great. excessive SQL queries, excessive javascript on page load, too many images instead of CSS, bloated table ridden HTML and too many ads and media content are a far greater drain on loading speed and performance than templating.

[dman_2007]

Personally, i don't use a separate template engine, php works fine for me. But i don't see anything wrong in using smarty either, It's a matter of personal preference. At the end of the day it doesn't really matter what you use, as far performance is concerned.

[atu]

Here is a piece of smarty code of an older project.

{section name="x" loop=$txt} 
  {assign_by_ref var="catid" value=$txt[x].id_cat}
  {$txt[x].date_online|date_format:"%d-%m-%Y"}
   <a href="index.php?tpl=text&id_cat={$catid[0]}&id_doc={$txt[x].id_doc}">{$txt[x].title}</a>
   {if $txt[x].logo}
     <img src="attach/docs/doc/{$txt[x].folder}/{$txt[x].logo}" width="{$txt[x].width}" height="{$txt[x].height}">
   {/if}
   {if $txt[x].head}
     <p>{$txt[x].head|strip_typo_bb:"latestarttext"}(...)</p>
   {elseif $txt[x].text}
      <p>{$txt[x].text|strip_typo_bb:"latestarttext"}(...)</p>
   {/if}
   {section name="dcat" loop=$catid}
     {op_doccat_branch id_cat=$catid[dcat] fields="id_cat,title" name="branch"}
     {section name=c loop=$branch}
      <a href="index.php?tpl=cat&id_cat={$branch[c].id_cat}">{$branch[c].title|strip_num}</a>
     {/section}
  {/section}
{/section} 

Any designer who can handle such a piece of code should be able to handle any piece of php code in templates.

The designer i work with on new projects have to work with php in templates. There is no discussion about that.

I can recommend to each designer who starts with his career to learn basic php. It's strange to focus on a second language layer who's advantage, if it exsists, is so minimalistic.

[Carl]

It all depends on how you implement smarty of any other template system. Two CMS that use templating systems that are a PIA are Pligg with Smarty and Joomla with pattemplate. They are the reason why designers become famous for creating a template that looks good using the systems. It is not easy.

[markbrown4]

I'm not sure how Smarty works, but for all templating systems I would recommend one that writes the transformed pages to static files on the filesystem. This way the files are not being re-generated every time a page is requested but rather just spitting out the static file that has been written using the template. This improves perfomance considerably as no PHP need be executed at all for content pages.

[dvduval]

It all depends on how you implement smarty of any other template system. Two CMS that use templating systems that are a PIA are Pligg with Smarty and Joomla with pattemplate. They are the reason why designers become famous for creating a template that looks good using the systems. It is not easy.

Yes, speaking of Pligg, I have this one job now where I am on the third programmer, because the first two hated Pligg, and the third one just wants to get done and move on. It sounds like they need to work on the way they implemented Smarty, as it seems to be a popular application aside from this.

Back to the original poster, I think what matters most is
1. how many people will be involved in the development of the project?
2. if it will be something that changes a lot over time?
3. will there be on programmer that is dependable over time?
4. will it involve multiple programmers over a period of time?
5. how large is the application going to be?

Really need to know this in order to provide a sufficient answer.

[peter_anderson]

i'd go with html with embedded PHP as it is easier to use. thats just my opinion, though

[Hal9k]

CodeIgniter uses a PHP based templating system and it works really well, it even has facilities for caching. There's some discussion on its use of extract() to unpack variables. If you're an aesthete, then you'll also like the way the HTML is properly indented.

I played around with extract, creating a function something like this:

function view($vars, $require_file)
{
  require_once $require_file;
  extract($vars);
} 

It requires the view template file, then extract() unpacks the variables into the function scope, though I haven't tested that works properly yet. Or you could do something similar to this blog post (CTRL-F on 'Use pure PHP templates').

Considering the vast amount of WordPress themes and the fact it uses native PHP templates, I don't think the 'stupid designer' arguments holds up. Templates inevitably involve loops and simple logic, so might as well do it in PHP.

Another caveat is support: PHP will last longer than a third party templating system.

[php_daemon]

Right know I use one simple template engine I made, and I keep asking myself, what was I thinking? It doesn't add absolutely anything but the overhead to parse.

The template engines, I think, don't give any real advantage over PHP. Especially if you're making your own engine. Smarty and others give some extra functionality you can use, but it adds a whole new language. So what's the difference from PHP? It just an extra library with its own language you must add in order to use.

If it's an issue for the designers to learn a language, the languages template engines introduce are no different from PHP. Why learn Smarty when you can as well learn PHP? No difference. Maybe if we used an engine that did not introduce a new language and made use of xml/xhtml, something like ASP.NET use. I see a benefit of using a language that they already know, just to keep them sane.

I guess if the library that Smarty or any other engine gives is essential for you, it may be convinient to use it. But if you're using it just to use a template engine or to supposedly make it easier for the designers, I don't think it is a good idea. Especially if you're developing your own engine -- just don't. We have php, html, css, javascript, xml we use in every project; do we really need any more languages?

[earl-grey]

One aspect, I'm surprised noone has mentioned yet, is security. In case you are developing a website, where users can upload own designs, PHP can't be used for templating purposes. And, depending on the application, allowing them to use HTML/CSS only may be rather restricting.

[Mastodont]

In case you are developing a website, where users can upload own designs, PHP can't be used for templating purposes.

Why? If you let them to define only block positions, you can have arbitrary template engine inside.

[earl-grey]

Why? If you let them to define only block positions, you can have arbitrary template engine inside.

Block positions may be not enough if you want to give them more control.

[orlandu63]

XSLT is an XML-based templating language. With it you can either choose to serve text/xml and have the user parse the data or HTML and have the server parse the data.

[Hammer65]

I guess if the library that Smarty or any other engine gives is essential for you, it may be convinient to use it. But if you're using it just to use a template engine or to supposedly make it easier for the designers, I don't think it is a good idea. Especially if you're developing your own engine -- just don't. We have php, html, css, javascript, xml we use in every project; do we really need any more languages?

If you aren't being paid to teach someone else a different language, then you really may not have a choice. A programmer shouldn't ever be afraid to learn a new language. We have to strive to continually expand our knowledge, or fall behind. We're programmers, it's what we do.

There are some, who both design and program to varying degrees. If you are an indy you pretty much have to do everything. Working for a company, is a little different. Smaller companies have plenty of employees that play multiple roles (I'm one of them), but many others who play very specialized roles. Smaller companies that are lucky enough to find someone talented in a specific area may not have the money or the time to train them in others. Larger companies have many more specialists.

You may say, that they should take it upon themselves to learn what they need for their jobs. If it's their own time however, it is nobody's right to expect them to do so, and impossible for anyone that doesn't know them intimately, to know for certain if they even can. I have four children. I'm lucky that I get the work done that I do. I would love to learn more languages, specs and techniques at a faster rate than I do currently.

Unfortunately, unless my employer somehow magically finds the work time for me to learn all that, I'm out of luck. The closest I can come sometimes is to hone my help desk skills by answering questions here.

Lets not turn this thread gradually from "I prefer this" or "I prefer that" to "you are an idiot if you do this or that". I know nobody has gotten there yet, but Smarty is a tool. It's widely used for good reason. If you don't prefer it fine.

There are plenty of tradeoffs between performance and development time and convenience that we make every day, that incidentally happen to include using a scripting language instead of a compiled language to do our development. If it makes sense to use a template engine, I say do it. Just keep it as simple as possible and weigh all the issues including performance. Compared to some of the performance sapping techniques I have seen some insist upon on this board, such as storing images in a database, using a template engine is a minor one.

[Hammer65]

XSLT is great, but considering how IE handles XML, good luck with that.

[Hammer65]

I think what he means is, it opens up the possibility for someone to upload dangerous (either intentionally or not) PHP code. Think about all of the inexperienced coders that post dangerous code here on this board. Now think about someone that is even less experienced or that actually decides to do damage.

This was my point about CMS systems. Nobody that we have developed CMS systems for, have IT people using it. They are all office people stuck with the job of updating the site. Allowing them to mess with PHP code is a risky prospect.

[Hal9k]

One aspect, I'm surprised noone has mentioned yet, is security. In case you are developing a website, where users can upload own designs, PHP can't be used for templating purposes. And, depending on the application, allowing them to use HTML/CSS only may be rather restricting.

What about Alex King's Wordpress Theme Browser?

Though obviously the themes need to be checked first.

[Kayzio]

I see it as Smarty = more server load and rendering time of web pages (even if minimal). why waste this bandwith and users time just to change the syntax of how you write some code. If you really want to make things editable by non programmers then make an admin panel where they have controls allowing them to change stuff w/o even touching the code itself.

[markbrown4]

XSLT is great, but considering how IE handles XML, good luck with that.

It should be parsed server-side, There's decent parsers for .NET, PHP and Ruby.

[33degrees]

I see it as Smarty = more server load and rendering time of web pages (even if minimal).

It's not really more server load if you're caching, and if you're worried about server load you should be caching anyway.