Although application code is separated from presentation, this does not necessarily mean that logic is separated. The application code obviously has logic, but the templates may have logic based on the condition that it is for presentation only. For example, if the designer wants to alternate table row colors or upper-case some assigned content, they can. This is presentation logic, something the programmer should not be concerned with. How often have you had some presentation displayed in a single column and then you wanted it in two or three columns, so the application code needs adjusting to accomodate this? A better approach is to assign the content in one single array and let the template handle the presentation. This will simplify your application and keep your templates flexible. Smarty supplies the tools to handle this kind of situation.
This doesn't mean that Smarty prevents you from putting application logic in the template, you have to have a bit of self discipline. Here is an example of embedding business logic in the template (that's right, avoid doing this if at all possible):
{if $smarty.session.user and ( $user_type eq "editor" or $user_type eq "admin" )}
<input type=checkbox name=edit value="y"> edit <br>
{/if}
|
The logic checks if the user is logged in and they are either an editor or administrator, then they are allowed to edit this so the edit checkbox shows up. That is logic that belongs in the application code. The template doesn't care about what credentials this user has, it just needs to know if the edit box is displayed or not! So let's look at a more suitable approach:
{if $edit_flag}
<input type=checkbox name=edit value="y"> edit <br>
{/if}
|
It is up to the application programmer to assign the $edit_flag, a simple and easy-to-understand variable in the template. This way the template is no longer relying on your underlying data structure. If the format of the session data structure ever changes, nothing needs to be adjusted in the template.
Now lets look at a few things you can do with Smarty. One thing it can do is custom functions. These are tags in the template that execute a certain task. Example:
{html_image file="masthead.gif"}
|
Here we have a function called "html_image". This function takes the image given in the "file" attribute and does all the work necessary to come up with the following HTML code:
<img src="masthead.gif" border="0" height="48" width="256"> |
The image function did the chore of figuring out the height and width and supplying the default border flag. Of course you could just use the static HTML tag in the template instead, but this demonstrates how a custom function can be utilized to simplify a very common task. The designer can focus on design and less on the technical stuff. Furthermore, if the designer decides to drop in a different size masthead image, the template does not need adjusting.
html_image is a function that comes with Smarty. You can also make your own custom functions. Here's another example of what one might look like:
{html_link type="article" id="abc123" text="Fire takes out Hotel"}
|
This is using a custom function called "html_link". It comes up with the following HTML code:
<a href="/display_article.php?id=abc123">Fire takes out Hotel</a> |
What does this accomplish? For one, the designer does not need to be concerned with the format of a URL to an article. With hard-coded URLs, what happens if one day the programmer decides to clean things up, and changes the URL syntax from /display_article.php?id=abc123 to /ART/abc123 ? We would have to edit every template with an article URL. This is just another example of how a template function can make templates easier to maintain.
