Summary: When setting up a website (or rebuilding one), you may have considered using a website templating system. This article considers the merits of templating systems and looks at one such system, SMARTY.
If your website has a lot of content, chances are, it’s database driven. You might have a fair amount of code, perhaps php, scattered around your pages, for connecting to the database and retrieving content. That’s the beauty of languages like php – you can drop the code directly into your HTML wherever you want to code some functionality. But as your site gets larger, this becomes a bit of a problem. If you want to do anything – change your database, add tables or fields, or delete them – you have to trawl through your pages and find every single instance of code to ensure you update it accordingly. It all gets a bit messy.
This is where a template system comes in. It allows you to separate the presentation of your website (sometimes called ‘display logic’ or simply ‘view’) from your application logic (the code that does stuff, like processing forms). With your code all safely in one place and your presentation in a different place, maintaining your website suddenly gets a lot easier. What’s more, you can have two teams working on the site – the coders doing the coding and the front end developers working on how the site looks, SEO and so on. The coders don’t break the front end developers’ work and vice versa. Everyone’s much happier.
So what templating system should you use? There are many available options – we’ll start with SMARTY which is a popular choice.
SMARTY templates
With smarty, what the user sees is stored in a template file (which has the extension ‘tpl’). Inside that template file, there are placeholders which are bits of dynamic information – for example, a customer’s details pulled from a database. They might look something like this:
<p>Your name: {$name}</p>
<p>Your address: {$address}</p>Front end web developers can easily drop these in place and move them around the template without breaking anything. If they accidentally delete a bracket or mispell something, the worse thing that can happen is that part of the placeholder is printed. Contrast this with errors in php which can result in a blank page or unfriendly error displayed to the user.
The resulting web pages are easy to maintain and even more easy to understand. Other benefits include:
- In built security features (optional) allowing control over what can and cannot be done in a template. This has benefits in situations where the page is to take user-submitted data.
- The templates are easy for non-coders to create and manipulate.
Smarty sounds brilliant! So why don’t more people use it? Isn’t it okay for SEO?
The first and main concern that people have is that the smarty code is large – there’s approximately 150kb of code for the required files smarty.class.php and smarty_compiler.class.php in total. In terms of processing power, it’s thought these are quite heavy if they are used for every request on your site. Instantly, you start to think about servers slowing down and site speed being affected – a genuine concern for us SEO experts.
In answer to these concerns, smarty users will tell you that unless you have a high traffic site with a slow server, any impact of using smarty is practically unnoticeable. The biggest overhead is when templates are changed – smarty will compile templates into native php code each time they are changed. But this is done behind the scenes, not at run time. Once a site goes into production, your templates likely won’t be changed and so won’t be recompiled. So, smarty_compiler.class.php won’t be loaded and the amount of code to be parsed is reduced to about 60kb.
There are things that you can do to improve smarty’s performance as well:
- You can use code accelerators like APC or PHP accelerator to decrease the overhead of loading the smarty library. APC is a free download used for caching and optimising PHP code on the server to improve server performance.
- You can cache the output from any or all of your web pages using Smarty’s caching functionality*. By doing this, you have an SEO benefit rather than detriment (as you’re making your pages faster).
*These suggestions appear in Quentin Zervaas’ book, ‘Practical Web 2.0 Applications with PHP’.
More benefits of using smarty can be found here. When you consider the benefits of using smarty or another templating system for more efficient website development, smarty seems like the natural choice. Of course, smarty isn’t the only templating system – there are many more good systems available. There’s 10 more listed here for you to consider, each having its own advantages and disadvantages to weigh up depending on what you want to use them for.
Separation of code
Going back to my initial comments on separation, developers may have noticed that I’ve advocated separation of code from view here and not considered whether the code itself needs better organisation. I think this is a whole topic in itself outside of whether you should use a templating system – but something that you ought to consider if you’re looking at building a new site and introducing a templating system. Very briefly, for database driven sites, best practice denotes that you implement an architectural pattern called ‘MVC’ (model-view-controller). Your models are the bits of code that manage your information, perhaps performing calculations and reporting to the view if there is a change of state. Your view is what we have described already – the part of the system that the user sees – it doesn’t do anything, it’s purely concerned with presentation. Finally, your controllers are the bits of code that process things – they receive input (perhaps from the view) and send that input off to the right model. The three kinds of code are kept separately and this makes maintenance of large database driven websites much easier.
The code accessing your data is outside of this MVC pattern. Practically this means that you should keep all code that accesses your database separate from other models. Again this makes things very easy to change if you make changes to your database.
There are plenty more good articles on separation of concerns and the MVC pattern on the web if you’d like to read up on this further.
Leave a Reply