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.

Vincent's rants are awesome! Rant away. It's going to be a tough one though - how do you cooperate on a site with a designer who only knows HTML, without using templates (or building a custom design interface)?

Also - why do none of the PHP template systems (that I'm aware of) use XML for marking up the "dynamic" parts of a template? Browsers ignore tags they don't recognise so for a designer, they could view a page without even seeing the XML or needing to interfere with it.

Originally posted by HarryF Also - why do none of the PHP template systems (that I'm aware of) use XML for marking up the "dynamic" parts of a template? Browsers ignore tags they don't recognise so for a designer, they could view a page without even seeing the XML or needing to interfere with it.

A rant, by request...

My apologies for posting this rant at so late a time, but I had to get in the right state of mind first, and I didn't want to let you down by posting a useless little rant. Also, it seems like I have a reputation to uphold...

I seriously believe that template engines like Smarty are a complete waste of our precious time. Luckily these packages are generally freely available, or they would be a complete waste of money as well. They do not add any features to PHP not already there, and by using them, dynamic web sites become more complex, a lot slower, and harder to maintain. That's right! Harder, not easier.

Making these bold statements is plain silly without explaining them, so that is what I will do in the remainder of this rant. As this is a genuine rant, I may unpurposefully hurt the feelings of some well-respected people (at least by me they are ), and I may not always appear to be the nice guy I actually am...

What does a template engine enable us to do? It allows us to separate content from business logic by supplying it with a template file. The template file is a normal HTML file, with special symbols (variables) in it instead of traditional content, and with special control structures (or: blocks) to influence the presentation logic.

A lot of you will probably say: "Yeah, right! This may work for simple examples as these, but for more complicated web sites, template engines are a real asset!" That is not true. The example I gave can easily be extended to larger, complex sites. Why is this possible? Because PHP already is a template engine. Examine all template engines you can think of, and compare their features with those of PHP. PHP has them all. And more.

So why do people think we need a template engine? The answer to that question is very simple: PHP has become too complex. Back in the old days, when PHP4 was just PHP/FI, the language was nothing more than a simple template engine. It had variables and blocks, and that was about it. Now, after a couple of years, PHP has been added to (but nothing was removed!) - it now has classes - and a large function library was written. And the latter is where the problem lies.

Pick any book on PHP from a shelf in your local bookstore, and look how result rows from a MySQL database are printed. (MySQL is of course the DBMS used in those books, which should already give you a clue about how bad the book is.) The mysql_-functions are used all over the place in the presentation layer.

Here, in these forums, we have learned people to not use those mysql_-functions directly, but use a database abstraction layer instead. This makes coding simpler (no need to know all those functions for the various DBMS's) and when they decide to use another DBMS instead of MySQL (and they undoubtedly will at some point), the conversion will be painless. What is the result of those lessons? People no longer use those functions directly, so that's good. On the other hand, they still place their business logic all over the presentation code. That's not so good. Most people don't know what to do about it, untill they learn about those yukky template engines. No need to carry on here...

At this point I also like to point out that saying "The layout must be strictly separated from the content" is a moot point. What is the layout? That's the colors, the fonts, the styles and so on. The plain HTML itself is the content. A couple of years ago cascading style sheets were introduced, and using these makes it possible to cleanly separate content from layout. I can change 99% of the layout of any of my sites by just changing the style sheet; there is no need to dive into the HTML. Only if the site needs a major overhaul the HTML must be changed. If your web designer tells you this isn't true, fire him.

Another answer to the question "Why do people think we need a separate template engine?" is the following: the biggest part of the PHP community (and the ASP community, for that matter) knows nothing about software architecture. Most of the PHP programmers don't know what an O(n^2) algorithm is, or who Donald Knuth is, or why a sorting algorithm can never be faster than O(n log n), or how Dijkstra's shortest path algorithm works. If they don't know the answers to these basic questions, how can we expect them to know how the design a software program? I'm not saying the majority of the community consists of a bunch of idiots, because that certainly isn't true. There are lots of bright, intelligent people out there, but they just don't know how to write software, because that isn't in their field of expertise. And can we blame them? Of course not. People who use PHP aren't software developers to begin with.

I have been programming now for about 13 years (I started when I was 12), and am currently graduating in University. In a couple of months, I will hopefully have a Masters Degree in Computer Science. This isn't meant to boast; it is meant to put things in perspective: I think I have the right to say that I know a little of what I'm talking about. I have been studying software architecture for many years know, and I still find it very hard. Programming is easy, yes. But developing software is extremely difficult. Don't trust anyone who tells you otherwise. Reading these forums, or examining PHP projects (PEAR, Smarty, Javuh, ...), I often become a little depressed. The questions asked are so simple; the mistakes made so stupid... But what can I expect? PHP wasn't built and isn't used by professional software developers (something I hope to become one day). The PEAR library is a badly designed (and badly implemented) library for several reasons. I have tried pointing these out several times (I had a long discussion with the PEAR developers), but most people simply don't get them, and praise the library to heaven. I try not to say something about this too often, because I'm likely to hurt feelings and there's no point in doing that. But then there are these people starting to praise these so-called 'template engines' and all I can think of is: "Here we go again..." Then I just have to say something about it. Again, I must stress that I don't blaim any PHP programmer personally, and that I don't think they are stupid. They are just working outside their field of expertise, that's all. It's like asking a carpenter to paint a house. He will probably do a nice overall job, but a real painter will undoubtedly do better.

Well, this more or less concludes my rant. From now on I will be nice again to everybody, and I won't be saying all too bad things about template engines, the PEAR library, or anything else I have a strong opinion about. Unless you want me to, of course...

Here are some questions/remarks you may have had when reading this rant, and my answers for them.

Q: If you use variables like '$title', as in your example, all over your code, then the business logic becomes a mess, and there is a possibility of clashes between such variables.
A: Then don't use these (global) variables. With little effort you can set up a simple class (or other structure) that stores the values for the page you are creating, allowing you to nicely separate presentation code from the business code.

Q: The 'better' template engines have a cache to make loading of pages much faster. Clean PHP doesn't do this, so the template engine is, in that case, faster!
A: Incorrect. The cache in a template engine is needed to store the parsed template in some other format (Smarty uses PHP for that), which can then be instantly restored. With clean PHP the format is already correct, so there is no need to use a cache. Less and simpler lines code, faster execution.

Q: Instead of using a template engine-specific language, our web designers - who know nothing about programming - are now required to have knowledge of PHP! We can't have that, now can we?
A: Why not? The template engine-specific language is nothing more than a minimal programming language with an ugly syntax. It has variables, conditionals, loops, and maybe even functions. As PHP is a full programming language, it has all of these constructs, and more. But that doesn't mean you require your web designers to know all there is to know about PHP. The set of requirements doesn't change at all. Just the basics will be enough. The added benefit is that if they want to, your web designers can start experimenting with PHP (or other scripting languages) much faster.

Q: You said maintaining a web site generated by some template engine is harder to maintain instead of easier. Why?
A: One reason is that an additional software package is involved. At least one person must be able to work with it. More knowledge is required. Also, not only the web site and PHP must be kept up to date; the template engine itself must be maintained as well. This means more work. Another reason is that the best solution for any problem is always the simplest one. Using a large, complex template engine where PHP itself suffices is not a simple solution. In other words: more work yet again.

i'm in a little of a hurry but i thought to let vincent have a go at 2 of my counter-arguments (for now ):

1) i develop scripts for clients -- they aren't complete idiots and as such know some HTML D)... i've had requests that they change the layout for them or that they be allowed to easily change the layout... wouldn't templates be a particularly good way to solve that problem... mind you templates are far more readable than PHP scripts... and one thing is they can show in WYSIWYG editors like Dreamweaver, perfect for a quick redesign of the layout

2) templates can be re-used... you can have 1 template for a particular section (or even the whole site) and then re-use them for each page, just changing the variable contents... i don't see that happening easily unless you write a class for that (like Perl/CGI or Python's HTMLgen)

If you'd let me I'd like to make a section on my site called "Vincent's Rants" and put all the ones I can find.

I don't really rant that much, now do I? I am flattered of course (I think that's the right emotion to express in this case...), but I wasn't aware that the majority of my posts are considered as rants from a seriously deluded guy...

Anyway, to answer redemption on how templates can make life easier: If you read my rant carefully (although I don't know why you would do that ), you'll see that I never said templates themselves are useless; I merely said third-party template engines are useless, which is something quite different. I just don't see why it would be easier for a web designer to write '{title|ucfirst}' (Smarty) instead of '<?= ucfirst($title) ?>' (PHP). It's even true that the latter is supported better by applications used by web designers, as for example Dreamweaver supports PHP, but not Smarty. There's nothing wrong with templates. On the contrary, using them is often a good idea. But as PHP is a template engine in itself, why would you need another one?

My own approach to developing web sites is different from the normal approach ('normal' being the one taught in the average 'PHP & MySQL' book). Instead of working my way back from a set of pages given by a web designer to a fully dynamic database-driven PHP site, I view a web site as I view any software product (surprise!). Most of you will know by now I write my software object-oriented, and the same goes for websites. A page on a site is represented by a class, which has a method 'show' that prints the page. Of course that method doesn't do all the work by itself; it calls other methods on the page object itself to show different parts of the page (the header, the menu, the footer and so on). The nice thing about this is that I can easily write a subclass that overrides parts of the original class to generate a page that looks more or less the same, but works slightly different. A subclass 'NewsPage' for example might look in some subdirectory, read all text files in it, and print their contents, ordered on the dates the files were created.

You might argue that this kind of approach makes it harder to separate the code from the HTML, but this is only partially true. It is true that a single HTML page is broken up in separate parts: headers, footers, and so on. But this is also the case for template engines. Depending on the complexity of the site, I can use simple classes that merely echo the necessary HTML inside the classes themselves, or classes that retrieve the content from (template) files on disk, or extract it from some database, or whatever.

To bind the different pages the site can create together, I use a different class 'Site' or 'Application'. This class knows about all pages the site can create, and the settings for these pages (like the specific class to use and the arguments that need to be passed to the class on construction). These settings can be read from a text file, extracted from a database, or restored from a cache file. Whatever is more appropriate. This design more or less implies that my sites have only page 'index.php' that can be influenced by setting the parameter 'page' to some (valid) value. It reads the 'page' parameter, gets the settings for that page, instantiates the right class, passes the settings to it, and shows it. From what I've seen of Fusebox, this is more or less what they do there, although I do it a bit simpler.

One important thing is that I can reuse this set of classes for many sites, and not just the one I currently happen to be working on.

There are many application frameworks out there, but I don't use one myself. I've examined a few in detail, and although some work pretty well, I haven't yet found a framework I like. The code I use in my daily work shouldn't just work well, it should look good too. In my book, good looking code is fully object-oriented, well layered code. I haven't found such a package yet, nor do I think I ever will (for reasons I have made all to clear in my rant..). All PHP code I use is code I wrote myself. That's code I understand, code I trust, and last but certainly not least, it's code that Looks Good (TM).

If you read my rant carefully (although I don't know why you would do that ), you'll see that I never said templates themselves are useless;

oh yeah i did read your rant carefully... wouldn't do you justice not to ... i know you never said templates were useless and i never thought or implied that you said that (if you read _my_ short post carefully )...

I merely said third-party template engines are useless, which is something quite different. I just don't see why it would be easier for a web designer to write '{title|ucfirst}' (Smarty) instead of '<?= ucfirst($title) ?>' (PHP).

why is it easier? first of all, you're relying on the fact that short_open_tags are 'on'... i admit that may sound a little nitpicky but i do it like this '<?php echo ucfirst($title); ?>', because i can't rely on them being on at each of my clients hosts... i fancy that somewhat harder for your average web designer to understand and it also somewhat makes the code look messier... what's wrong with getting a 3rd-party template then if it simplifies the code at your average web designers end so they can concentrate on making pretty stuff ?

It's even true that the latter is supported better by applications used by web designers, as for example Dreamweaver supports PHP, but not Smarty. There's nothing wrong with templates. On the contrary, using them is often a good idea. But as PHP is a template engine in itself, why would you need another one?

yes Dreamweaver MX (which not all my clients would have) does support PHP but you don't get what i'm trying to say i think: when i deal with the templates, or when i pass them on to a designer, we shouldn't have to care about PHP code embedded in the code... the template is the HTML page and shouldn't depend on the business logic that will use the template... what they should ideally see is a HTML file with placeholders, and they should be able to work around these placeholders easily and do their stuff... PHP on the other hand is foreign to (most of) them, while templates are not... designers know templates and how they work, as they've been (or they should have) working with them all the time... throw PHP code at them and they may just start barfing ... that's my point

You might argue that this kind of approach makes it harder to separate the code from the HTML, but this is only partially true. It is true that a single HTML page is broken up in separate parts: headers, footers, and so on. But this is also the case for template engines. Depending on the complexity of the site, I can use simple classes that merely echo the necessary HTML inside the classes themselves, or classes that retrieve the content from (template) files on disk, or extract it from some database, or whatever.

i like your approach and i do the same too for myself (my own scripts) though i don't use an OO approach (mere functions)... but what you're doing is essentially a template engine too, isn't it? you're creating your own template engine on top of PHP (the 'other template engine')... it may not be 3rd-party (meaning someone else's code) but it is still an 'unnnecessary' layer on top of what already is a template engine (as you proclaim) is it not?

That's code I understand, code I trust, and last but certainly not least, it's code that Looks Good (TM).

amen to that ... i believe in that too... so much so that it took me awhile to get used to the idea of using other peoples' scripts, code snippets, libraries... but think about it: if you use Perl, you're using modules which are other people's code, even the Perl interpreter is other people's code... the same goes for any other programming language... code-reuse is a Good Thing too... but like you say it should be code with quality, efficiency, security and stability...

someone with strong opinions like yours make for good discussions and a new learning experience every time Vincent

Mattias - looking at that code, I don't think it solves the problem Redemption wants to solve - that designers with HTML knowhow only will build the site design. That looks to me like it's going to take a .NET coder use it.

Originally posted by HarryF Mattias - looking at that code, I don't think it solves the problem Redemption wants to solve - that designers with HTML knowhow only will build the site design. That looks to me like it's going to take a .NET coder use it.