PHP Template with Smarty(.tpl)

Why would I use Smarty (when PHP is a template engine)?

Some might argue that Smarty does what PHP can do already: separate the presentation from business logic. The PHP programming language is great for code development but when mixed with HTML, the syntax of PHP statements can be a mess to manage. Smarty makes up for this by insulating PHP from the presentation with a much simpler tag-based syntax. The tags reveal application content, enforcing a clean separation from PHP (application) code. No PHP knowledge is required to manage Smarty templates.

The importance of this separation is situational. It is commonly more important to web designers than it is to PHP developers. Therefore, Smarty is commonly a good fit when the roles of developers and designers are separated. There is no right or wrong answer: every development team has their own preferences for managing code and templates. Aside from a clean tag-based syntax, Smarty also offers a wide variety of tools to manage presentation: granular data caching, template inheritance and functional sandboxing to name a few. Business requirements and the PHP code Smarty is being used with will play a large role in determining if Smarty is a good fit.

In cases where efficient template management is crucial, or the case where web designers (not PHP developers) are managing templates, the strengths of the tag-based template syntax are quickly realized. If the project size scales to hundreds or thousands of templates, template inheritance keeps template maintenance streamlined. What little Smarty adds technically (a tag-based syntax + 1-time compile step) is easily overcome by the time saved with template maintenance.

Smarty is clearly not meant for every project. It is just one solution for managing the presentation of your PHP applications. Your business requirements along with your development team preferences will largely decide of Smarty is a good fit. Be sure to read All about Smarty, Use Cases and Work Flow, Template Inheritance and Syntax Comparison. And of course, install Smarty and give it a try.

Template Syntax: Smarty vs PHP

The PHP programming language is great for code development, but many will argue that embedding its terse statement syntax into HTML can be difficult to manage. Smarty makes up for this by insulating PHP from the presentation with a much simpler tag-based syntax. The tags reveal application content within the presentation in a clean, intuitive manner. No PHP knowledge is required to manage Smarty templates.

To demonstrate, let’s compare PHP and Smarty syntax. We’ll start with a simple variable, using PHP’s short-tag syntax.
PHP

<?=$foo?>

Smarty

 {$foo}

Note that the PHP syntax uses 5 punctuation characters to display a simple variable: <?=?>, whereas Smarty uses 2: {}. (We ignore the $ since it is always present in both syntaxes.) Now lets compare array access:
PHP

<?=$foo['bar']?>

Smarty

{$foo.bar}

PHP uses 9 punctuation chars, and Smarty uses 3. Even with this simple example, you can begin to see how the syntax noise is greatly reduced by Smarty. Moving on, let’s try a foreach loop:
PHP

<?php foreach($foo as $bar): ?>
 ...
 <?php endforeach; ?>

Smarty

{foreach $foo as $bar}
 ...
{/foreach}

PHP uses 18 punctuation chars, and Smarty uses only 5. Now let’s try some real-world use, mixing things with HTML tags:
PHP

<?php if(!empty($foo)): ?>
 <?php foreach($foo as $bar): ?>
 <a href="<?=$bar['zig']?>"><?=$bar['zag']?></a>
 <a href="<?=$bar['zig2']?>"><?=$bar['zag2']?></a>
 <a href="<?=$bar['zig3']?>"><?=$bar['zag3']?></a>
 <?php endforeach; ?>
<?php else: ?>

There were no rows found.

<?php endif; ?>
 Smarty
 {foreach $foo as $bar}
 <a href="{$bar.zig}">{$bar.zag}</a>
 <a href="{$bar.zig2}">{$bar.zag2}</a>
 <a href="{$bar.zig3}">{$bar.zag3}</a>
{foreachelse}</pre>
 There were no rows found.
{/foreach}

In the short example above, Smarty saved 110 characters, or a 36% syntax reduction. Also notice that Smarty takes care of boilerplate functions wherever it can, such as the empty() test in the above example. Smarty cleans up the syntax of templates, making them less fragile.
PHP short-tags

Notice we have been using the PHP short-tag syntax <?=$foo?> for variable output. This is used in PHP as as shortcut to the longer syntax of <?php echo $foo; ?>. This helps shorten things up bit, but you still don’t gain much in readability. Many PHP devs will tell you to avoid short-tags anyways, as this defeats cross-system compatible code since short-tags are optional. Lets compare the long syntax to a Smarty variable:
PHP

<?php echo $foo; ?>

Smarty

{$foo}

Even with this short example, you can see a 13 character savings (69% shorter) to display the same thing. Now let’s see this mixed in with some HTML:
PHP

 <a href="<?php echo $bar['zig']; ?>"><?php echo $bar['zag']; ?></a>
 <a href="<?php echo $bar['zig2']; ?>"><?php echo $bar['zag2']; ?></a>
<a href="<?php echo $bar['zig3']; ?>"><?php echo $bar['zag3']; ?></a>

Smarty

 <a href="{$bar.zig}">{$bar.zag}</a>
 <a href="{$bar.zig2}">{$bar.zag2}</a>
<a href="{$bar.zig3}">{$bar.zag3}</a>

Delimiter Confusion

Another issue with PHP tags is that they share the <> characters of HTML tags. In the application code this isn’t an issue, but mixed with HTML, <?php ?> tags are a maddening process to tell them apart from the HTML tags. This also blurs the line between application and presentation separation since any PHP logic can be injected into a template. This is where a simple {tag} syntax is a huge welcome. Smarty keeps the presentation short and concise, well-defined, less error prone and easy to maintain.
Simplified Logic

Smarty features simplified, english-reading logic statements. The following example displays the odd numbers of 1-20 (1,3,5,7,…):

PHP

 <?php for($x=0; $x<20; $x+=2): ?>
 <php echo $x+1; ?>
<?php endfor; ?>

Smarty

 {for $x = 1 to 20 step 2}
 {$x}
{/for}

Which is easier to understand? How about for the non-developer types?

The following example loops over the $foo array and prints the value in a table cell. Every 4th row it prints </tr><tr> to start a new table row:
PHP

 <?php $counter=0; ?>
 <?php foreach($foo as $bar): ?>
 <?php if(($counter+1) % 4 == 0): ?>
 </tr><tr>
 <?php endif; ?>
 <td><?php echo $bar; ?></td>
 <?php $counter++; ?>
<?php endforeach; ?>

Smarty

 {foreach $foo as $bar}
 {if $bar@iteration is div by 4}
 </tr><tr>
 {/if}
 <td>{$bar}</td>
{/foreach}

The next example lower-cases and html-escapes a variable:
PHP

<?php echo htmlspecialchars(strtolower($foo),ENT_QUOTES,'UTF-8'); ?>

Smarty (notice the natural left-to-right statement flow):
Smarty

{$foo|lower|escape}

lower and escape are two of many built-in plugins that come with Smarty. They contain powerful features aimed specifically at presentational output. Do you want to javascript-escape the variable instead? One simple parameter:
Smarty

{$foo|lower|escape:javascript}

Which of the above do you think a designer would rather follow? Short, concise syntax is key to fast deployment and easy maintenance.

These are just a few examples of how Smarty saves you time managing templates, insulates templates from PHP code, and makes template maintenance easy, even for the completely inexperienced user. See also All about Smarty, Use Cases and Work Flow, Template Inheritance and Why use Smarty.

Template Inheritance

Template inheritance is an approach to managing templates that resembles object-oriented programming techniques. Instead of the traditional use of {include …} tags to manage parts of templates, you can inherit the contents of one template to another (like extending a class) and change blocks of content therein (like overriding methods of a class.) This keeps template management minimal and efficient, since each template only contains the differences from the template it extends.
A Use Case Demonstration

The challenge: Let’s say we are creating an HTML page, and it requires some custom Javascript/CSS files loaded within the <head></head> of the document. The problem is that this is defined in the header.tpl, which was included further up the page. There are many ways to address this, but they can get quite messy. Let’s make this task an easy one, with Template Inheritance, new to Smarty 3.

Before template inheritance, we were stuck with using {include …} tags to share content such as headers and footers. Here is an example:
Example Without Inheritance

 header.tpl
 <html>
 <head>
 <title>{$title|default:"Default Page Title"}</title>
 </head>
 <body>
 footer.tpl
 </body>
 </html>
 mypage.tpl
 {include file="header.tpl" title="My Page Title"}
 My HTML Page Body goes here
 {include file="footer.tpl"}
 output of mypage.tpl
 <html>
 <head>
 <title>My Page Title</title>
 </head>
 <body>
 My HTML Page Body goes here
 </body>
 </html>

Now let’s rewrite this with template inheritance:
Example With Inheritance

 layout.tpl
 <html>
 <head>
 <title>{block name=title}Default Page Title{/block}</title>
 </head>
 <body>
 {block name=body}{/block}
 </body>
 </html>
 mypage.tpl
 {extends file="layout.tpl"}
 {block name=title}My Page Title{/block}
 {block name=body}My HTML Page Body goes here{/block}
 output of mypage.tpl
 <html>
 <head>
 <title>My Page Title</title>
 </head>
 <body>
 My HTML Page Body goes here
 </body>
 </html>

Instead of managing our page layout in several files (header.tpl, footer.tpl, etc.), we now manage it in one cohesive template (layout.tpl), and define the changeable blocks of content with {block …} tags. Now you can simply extend the layout.tpl (which basically copies it) and then customize any of the defined block elements. You can have any number of child templates chained together, thus the concept of inheritance.

So back to our initial challenge, how do we address the need to have custom Javascripts/CSS loaded in the header? Simply add a new block to the layout.tpl, and customize it in the child template:

 layout.tpl
 <html>
 <head>
 <title>{block name=title}Default Page Title{/block}</title>
 {block name=head}{/block}
 </head>
 <body>
 {block name=body}{/block}
 </body>
 </html>
 mypage.tpl
 {extends file="layout.tpl"}
 {block name=title}My Page Title{/block}
 {block name=head}
 <link href="/css/mypage.css" rel="stylesheet" type="text/css"/>
 <script src="/js/mypage.js"></script>
 {/block}
 {block name=body}My HTML Page Body goes here{/block}
 output of mypage.tpl
 <html>
 <head>
 <title>My Page Title</title>
 <link href="/css/mypage.css" rel="stylesheet" type="text/css"/>
 <script src="/js/mypage.js"></script>
 </head>
 <body>
 My HTML Page Body goes here
 </body>
 </html>

As you can see, we can now easily customize header content from the child template. This is the basics of template inheritance. It cleans up template management, and makes tough problems trivial!

Best Practices

Although Smarty helps facilitate the separation of business logic (PHP) from presentation, that does not mean it prevents poor implementation. No different than any other software, Smarty has a learning curve. Smarty does not guarantee good application design or proper separation of presentation, this still needs to be addressed by a competent developer and web designer. We’ll cover some of the more common pitfalls and how to avoid them.

Note: With Smarty we typically refer to the PHP developer and the template designer as separate roles. Although this could be the same person in real life, it is good to think of them as separate roles so you can clearly understand what belongs in PHP and what belongs in templates.

Now lets get to the first problem: embedding PHP in templates.
1. Do not imbed PHP!

This is by far the biggest mistake with Smarty templates. When Smarty was first developed, the {php} tag was provided as a sort of “last resort” way of solving a problem. Experience has revealed that directly embedding PHP is not only unnecessary, it creates more problems than it solves. The {php} tag is strongly discouraged, and is now deprecated in Smarty 3.

Despite the discouragement, lazy developers continue to fall on the {php} crutch, as this may seem (at first glance) to be the quickest path to implementation. However, this approach just leads to more problems. The correct approach is to implement a plugin and do the PHP logic outside of the template.

First lets look at how not to use Smarty.
Example problem: solved the wrong way

Let’s say we have this existing PHP function that grabs the current weather forecast and displays it in an HTML table.
PHP

 function get_forecast($zipcode) {
 // some weather class we use to do the fetching
 include_once('weather.php');
 // get the forecast from the weather station
 $forecast = Weather::forecast($zipcode);
 // now mark up and return
 $output = "<table>";
 $output .= "<tr><td>Temp:</td><td>".$forecast['temp']."</td></tr>";
 $output .="</table>";
 return $output;
 }

So now our esteemed PHP developer wants to implement this in a Smarty template. Easy, right? We just throw it in with {php} tags:
Smarty

{php}echo get_forecast($zipcode);{/php}

So we basically “escape” the template for a moment into PHP code and run the function. Uh oh, we have a problem. Our $zipcode variable is a template variable, and it won’t “just work” in a {php} block. So we have to get that from the Smarty object. Have no fear, with a little more code we can access that:
Smarty

{php}echo get_forecast($this->getTemplateVars('zipcode'));{/php}

Oops, we have another problem. Our PHP function get_forecast() is not available. We must first include this file. Let’s say we have a PHP constant MY_APP defined and we know the filepath relative to that. So we’ll throw in an include() statement to include the file:
Smarty

 {php}include(dirname(MY_APP).DIRECTORY_SEPARATOR.'forecast.php');
 echo get_forecast($this->getTemplateVars('zipcode'));{/php}

Although this technically works, we just did exactly what Smarty was intended to avoid: We now have a syntactical mess, and we have business logic in our template (PHP constructs and logic that have nothing to do with the presentation.)

Let’s say the template designer looks at the output and decides that we don’t want the weather in an HTML table. Instead, we want a <div> container with some stylesheet markup. So the designer heads off to the template to change it. Finding this in the template is not a welcome sight. Since there is no way to manage the markup from the template, the designer needs to either inform the PHP developer what to change, or locate and change the PHP code themselves (oops, there goes the separation.) This is probably not the best implementation.
Example problem: solved the right way

Now let’s solve the same problem by making a simple template plugin. By implementing a plugin we will keep business logic out of the template, and move all presentational elements into the template, establishing the correct separation. We can either create a new plugin file in the Smarty plugins directory, or we can make a PHP function (or class method) somewhere in our application code and register it with Smarty manually. Let’s go with the plugin file method. Here is what our plugin file will look like:
PHP

 <?php
 /*
 * Smarty plugin
 * -------------------------------------------------------------
 * File:     function.get_forecast.php
 * Type:     function
 * Name:     get_forecast
 * Purpose:  gets the weather forecast
 * -------------------------------------------------------------
 */
 function smarty_function_get_forecast($params, $smarty)
 {
 // some weather class we use to do the fetching
 include_once('weather.php');
 // get the forecast from the weather station
 $forecast = Weather::forecast($params['zipcode']);
 // now mark up and return
 $output = "<table>";
 $output .= "<tr><td>Temp:</td><td>".$forecast['temp']."</td></tr>";
 $output .="</table>";
 return $output;
 }
 ?>

And now let’s implement this in our template:
Smarty

{get_forecast zipcode=$zipcode}

Now this looks a whole lot better. The template now contains something very easy to understand. We are not quite finished: remember that we want to be able to handle the presentation on the template side, so we need to move the markup into the template. This will also simplify our plugin logic, as it no longer has to deal with presentation (as it should be.) Let’s make those changes:
PHP

 <?php
 /*
 * Smarty plugin
 * -------------------------------------------------------------
 * File:     function.get_forecast.php
 * Type:     function
 * Name:     get_forecast
 * Purpose:  gets the weather forecast
 * -------------------------------------------------------------
 */
 function smarty_function_get_forecast($params, $smarty)
 {
 include_once('weather.php');
 // get the forecast from the weather station
 $forecast = Weather::forecast($params['zipcode']);
 // assign forecast data directly to given template var
 $smarty->assign($params['assign'],$forecast);
 }
 ?>

And in the template:
Smarty

 {get_forecast zipcode=$zipcode assign="forecast"}
 <div>Temp: {$forecast.temp}</div>

We’ve moved the business logic (PHP) into the plugin, and we moved presentation (HTML/CSS) to the template. We’re done! Now compare this solution to the previous example, and you can probably recognize what a programmer and template designer would rather work with. This syntax is very easy to understand and maintain.

Of course, there are other ways to approach this problem. You could simply assign $forecast to the template from the PHP code, foregoing the need to create a {get_forecast} plugin altogether:
PHP

 $smarty->assign('forecast',get_forecast($zipcode));
 Smarty
 <div>Temp: {$forecast.temp}</div>

That works too. The first approach allows us to independently fetch the forecast from any template. You can decide for yourself the best way to implement it.
2. Keep PHP constructs separate!

Another common pitfall is embedding PHP constructs (such as objects/classes/functions) into a template when it is better to keep them separate. Let’s take an example of editing an article. We display an article on the page and if the current user is an editor, we want to show the edit buttons too. In our PHP logic we have a $roles object we use to check the user’s role:
PHP

if($roles->isEditor($_SESSION['user_id'])) { /* do something */ }

The first thing a developer may be tempted to do is assign the $roles object directly to the template and use it as such:
Smarty

 {if $roles->isEditor($smarty.session.user_id)}
 ... show edit buttons here ...
 {/if}

This introduces several problems. First, we are creating a tight coupling of the underlying PHP object structure to the template, e.g, we can no longer make changes to the application without directly affecting the template. Second, we are introducing application logic into the template (accessing user roles.) Third, this complicates the template syntax, and you expose PHP class/methods/parameters that may not have anything to do with presentation. The template designer does not need to deal with user roles, they only need to know whether or not to show the edit buttons.

Here is an approach to keep things separate. In our PHP logic, we will assign a simple flag to Smarty:
PHP

 // assign a flag for Smarty
 $smarty->assign('show_edit_buttons',
 $roles->isEditor($_SESSION['user_id']));

And in our template, we use the flag:
Smarty

 {if $show_edit_buttons}
 ... show edit buttons here ...
 {/if}

Now our template focuses purely on the presentation. In some cases a flag name like $is_editor may be more appropriate, depending on what contexts it is used. But you get the basic idea. Keep the business logic out, and focus on presentation.

Now that said, embedding PHP constructs into templates is a fine line. There may be instances where this works better for your implementation. You have the ability to embed them, just be sure you understand the implications.
3. Keep business logic separate!

It may be tempting to create template functions that do neat things, but remember to keep them focused on presentation and not business logic. Here is a prime example of writing a template function that breaks the separation:
Smarty

 {sql statement="select * from categories order by catname limit=$start,$limit" assign="result"}
 {result.catname}
 {/sql}

There are several problems here. First, direct SQL statements are business logic. The designer should not need to know anything about SQL or where content comes from, let alone control exactly how this content is retrieved. Second, we open a potential security hole with SQL statements in the templates. The designer could easily break the SQL statement, the parameters could be wrong, or (depending on where your parameters come from) malicious injection attacks could happen. Here is a much better approach to the above example, using a plugin that cleanly separates the business logic from presentation:
Smarty

 {get_categories limit=10 assign="result"}
 {$result.catname}
 {/get_categories}

In our get_categories block plugin we handle the parameter cleansing and SQL access, and the template focuses purely on presentation. You could also assign $result directly to the template from PHP (probably the more common approach), but this design allows us to retrieve the categories arbitrarily from any template. Use your own judgement for your implementation.
4. How to identify business vs presentation logic

Business logic is normally any logic that does not deal directly with the presentation, or display of content. For instance, regular expressions embedded in the template are normally better handled in PHP, either in a plugin or before content is assigned. Although Smarty ships with a regex_replace modifier, it is normally better to do this in PHP.

Here is an example of using regex_replace. We want to make all emails into links in the description text:
Smarty- business logic in template (bad!)

{$description|regex_replace:"!(\w+@\w+)!":'<a href="mailto:$1">$1/a>'}

It is not immediately obvious what is going on here, unless you are a regex guru. This terse template syntax is a clue that we have business logic in the template. A better approach is to use a custom plugin (modifier):
PHP

 <?php
 /*
 * Smarty plugin
 * -------------------------------------------------------------
 * File:     modifier.link_emails.php
 * Type:     modifier
 * Name:     link_emails
 * Purpose:  make emails in text into HTML links
 * -------------------------------------------------------------
 */
 function smarty_modifier_link_emails($string)
 {
 return preg_replace('!(\w+@\w+)!','<a href="mailto:$1">$1</a>',$string);
 }
 ?>

Smarty

{$description|link_emails}

Now it is perfectly clear what is happening, regardless of the template designer’s knowledge of regular expressions.

Recall that we keep the template designer and application developer roles separate. The purpose of this is to define a separation between presentation and business logic. If the person editing the templates is quite familiar with PHP, that doesn’t mean these rules should not apply. The purpose is to keep the business logic out of the template. This will go a long ways toward fast development, concise template syntax and easy maintenance.

When making decisions where to put logic (in templates or in PHP), try to keep the templates focused on presentation. If you find yourself struggling with template syntax, making syntax too complicated, or trying to access PHP from the templates, there is usually a better approach. Think about the separation, and how to implement it in a way that keeps template syntax minimal and focused on presentation.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s