Slashdot Mirror
PHP Template Engines?
kubed asks: "I've recently learned how to use PHP template engines to separate business logic from presentation. Some argue that template engines make applications easier to maintain and make for cleaner code. Others argue that template engines introduce unnecessary overhead and require too much additional processing power. Do the readers of Slashdot think that it is important to use templates or are they just an extra unnecessary layer? There are dozens of PHP template engines to choose from including Smarty, phplib, and bTemplate. Which template engines do you have experience with and which ones have the best performance?"
There are really two things to consider when using template languages like PHP and ColdFusion:
1) Is the rapid development style worth the processing overhead and system-independence?
2) Are you prepared to take the extra time to make the code clean after said rapid development?
Granted, any language can be misused to create horrible code, but with rapid development with template languages, you have to be careful not to let the ease and simplicity of the language lull you into poor programming. However, you do not need to use extra "stuff" to accomplish this specifically, if you are careful to code your data access modules separate from the presentation logic in the first place, which is just good programming style in general.
I am currently just two weeks away from going live with a large web application written in PHP using Smarty. I can't speak to performance, as it is a complex application with a low number of clients, but for my needs it has been very acceptable. As far as the interface and syntax, I am in love with Smarty. I had become disenchanted with PHP due to the spaghetti code when you don't use such an engine. Smarty .. mmm, it has brought me back. In fact, I'm writing a templating engine for Ruby based on the Smarty syntax.
Smarty -- highly recommended!
I have a template engine based on standards. It's called XSLT, and it's built into the most recent PHP versions. Especially nice is the 5.x branch, since it has been completely rebuilt for speed and compatibility to libxml2. I have a site full of XML, and I transform it with a central XSL template file into the displayed content. It's a shallow learning curve, and I can change the entire site's layout by a few XSL tweaks. For me, it is the perfect solution.
Heute die Welt, morgen das Sonnensystem!
Ok, so I'm a little biased having written my my own template engine. However, they have their plusses and minusses.
On the positive side, it really helps separate code from display, which makes everything look neater -- as in clean, not as in "gee whiz". HTML is easier to read and it's easier to abstract everything. I'm sure you know the arguments for it already. If you need to change something, all you do is find the template and you can see everything in one clear shot, instead of digging through mountains of PHP logic.
Additionally, if you use a good template engine, it will make your pages load faster by using a caching system. Basically, if your page doesn't change very often, it will save a static copy of all of your PHP logic and return that to the browser instead of making the database calls and other operations that eat up processing speed. I did notice a difference when I wrote my site.
However! There are some important things to remember. Unless you cache your site, it will probably not be any faster. Smarty is, in my opinion, bloated and slow. It tries to do too much and takes forever to load and use. (By forever, I mean like 0.1 seconds to load a page created by Smarty versus 0.005 seconds to load the equivalent page from pure PHP.)
Moreover, websites made with templates are summarily locked into that template engine and new developers will have difficulty figuring out what the heck you did without a good bit of explanation.
One more point to consider is the fact that when using template engines, usually you're limited in the tricks you can pull on your website. Template engines seriously restrict your ability to do cool things with PHP in the display process.
Finally, template engines introduce new flaws into your website. Sometimes those flaws are really bad and affect the performance of your site and then the developers are sometimes difficult to work with and then you have this piece of code that you didn't write that you have to work around.
Those are just things to consider.
I write php and for any relevantly grouped output, I surround it in html div tags. I use a lot of div tags. E.g., to deal with a list of links with descriptions, the entire list is enclosed in a div, each link plus it's description has it's own div, each link has it's own div, and each description has it's own div.
I keep a list of the classes/ids of the divs. I heavily organize the code so that every element can easily be referred to by a class or id according to a heavily commented list of selectors.
The PHP file is all structure/programming logic. I put all content in some sort of database.
Then I write cascading style sheets. You'd be amazed at how many different ways you can make the page look. And not just different colors/font sizes; you can make a sidebar float left or right, or be across the top; you can make links' subsections unfold, or stay invisible until you're in that section; in short, you can make the page be layed-out however you want.
(A few caveats: I've found, in making the css cross-browser compatible, that sometimes you need to do a few work-arounds that pollute the structured PHP document, things like: make a extra div around a div; maybe use a conditional statement to show an INPUT or a BUTTON tag. But you usually need to pollute your non-css HTML anyway if you want to do some sort of tricky design that is cross-browser compatibile and that degrades gracefully.)
For me, a separate PHP template engine means that the template itself will be polluted: you'll have HTML that's trying to do design, instead of just describing the page's structure. And of course, the template page will need some programming logic like loops and conditionals.
Better for your designers learn css than make them deal with some half-assed half-HTML, half-PHP template.
1) With PHP templates
--
* programming logic in php files
* content in a database
* structure/design in template
2) With no templates but using css
--
* programming logic & document structure in PHP files
* content in database
* design in css
Two is cleaner, no?
I have yet to see a PHP templating engine that can do more than PHP itself. Variables, tag substitution, subfiles, looping... It's all in there at extremely low overhead. You just have to use PHP the same way you'd use the templating engine (separate business logic and content, etc).
Can anybody explain what any of these templating engines gives you that can't be found in PHP natively?
Check out the SitePoint forums for Advanced PHP. The pro's and con's of template engines have been discussed over there in length and it is just a great resource for advanced PHP topics. SitePoint Forums.
Also, take a look at Harry Fuecks website PhpPatterns. He also has detailed information about PHP templating and the theory behind the code.
I have been working on my own templating system / toolkit for quite a while. I use a central wrapper, and include "handlers" parse and handle various other PHP and non php data sources. Using this approach I can integrate other systems and seamlessly tie NUKE, PHPBB , PHPSHOP and other common php applications all with my own template engine.
:)
My main purpose is to design interactive applications or "admin sites". I have code templates (seperate from the layout templates). That enable me to generate an decent looking application, with the ability to add/update/delete/browse/copy/update multiple records based on a mysql table in under an hour. I have code that builds a config file based on the database schema, and provides basic data validation for things like phone numbers, credit cards, date ranges, zip codes, etc. So when customers approach me with custom application requests 85-90% of the coding is done.
A side benifit for this is the business logic can be seperated from the infra-structure and templating logic, so the site are easily maintainable (and upgradable, since my template handler scripts, can be swappped out and upgraded). This also helps security, because I will disable certian handlers, based on the authenication level, and can store the handler scritps outside the web directory tree, so if you don't have the proper rights the file handler simply does not exist, or a lesser version of it does.
Another important benifit is that this extra layer of seperation, and pre-coded templates help me maintain a very consistent look across the various admin screen with very little effort (the html forms are automatically generated based on the DB schema, and the user defined config file). That way if you add a field to the database, it instantly appears in your application, no need to update HTML/PHP code, its all done automatically.
The vast majority of the core application is written and maintained by me. I distribute it to my clients under the GPL, but I have not formally released the application other than to people who are using it.
They can be slow, and cumbersome if they are too database dependent, but because the logic and data and layout are all well organized it is very easy to automatically create static pages if need be. (This is another feature of my toolset, albeit an incomplete one).
Anyway, without the structure of a templating system I would not be able to stay in business. I don't believe in plugging my business on slashdot. But, if you are really interested in knowing more you should be able to track me down via my slashdot info. Ask for Brandon
-MS2k
Isn't PHP essantially a template engine in itself? What's the rationale for using a template engine from within a template engine?
The notion of templating in PHP (or any web platform) is described by Martin Fowler in Patterns of Enterprise Application Architecture as the Template View.
Implementation of the Template View is examined in some detail at http://wact.sf.net/index.php/TemplateView, which begins looking at "Why use templates" then examines different styles of templating, in terms of their markup and the API they provide to populate the template with data. The purpose is to lay this discussion to rest once and for all.
Where PHP's concerned, the real question is why has everyone (and their dog) written their own template engine? In an ad hoc survey we counted over 80 public domain template enignes "out there"
What's even more puzzling is why 90% of them all look the same with markup like;
{if $font="bold"} Hello World! {else} Hello World! {endif}...and a pinhole API like;
$tpl->set('font','bold');My guess at the reason why is public here
.As to what template engines in PHP are actually worth using, there are only two IMO;
The first is PHP itself - use some self discipline and keep the pages where code gets mixed with HTML to the most basic PHP syntax - just the flow control statements like if/else, while and foreach.
The second is any which can offer templating capabilities similar to Java's JSTL or ASP.NET. Which is where WACT comes in. Check the examples to get the idea.