The Dynamic Duo of PEAR::DB and Smarty

by Joao Prado Maia
04/17/2003

Our Goals

Total separation of business and template logic is an often-sought goal in advanced web application development. Many times, PHP leads to a compromise. Some code sets implement features by embedding markup in the business logic. Others put business logic in the template side.

While this was true even for my own software development, recently I came to the conclusion that it didn't need to be that way. By simple trial and error, developing new versions of my own libraries and reusing other libraries for my projects, I have found a better way to integrate a database-backed application with a powerful template engine.

I'm obviously talking about PEAR::DB and Smarty here, and I will show throughout this article my experiences and best practices in integrating these two amazing libraries. You will end up with a really nice setup, having an excellent separation between business logic and template logic.

Database abstraction packages are a common part to most programming languages, such as Java's JDBC or Perl's DBI. PHP is no different -- there are countless database abstraction libraries available. PEAR::DB is one of the newer data access abstraction packages, and it was described in my article PEAR::DB Primer. Template libraries are also a pretty common feature of most web related technologies, such as Perl or Cold Fusion. Smarty is a template engine maintained by Monte Ohrt. Andrei Zmievski, a core PHP developer, also contributed to its development. Smarty is different from the existing solutions because of its simplicity and available features, such as the ability to cache templates into PHP scripts which gives a big boost in performance.

The Setup

While I do love to work with PEAR::DB and Smarty, I always try to make my code as "future-proof" as possible. I want to develop my PHP scripts in a way that is forward-compatible (as much as possible) with whatever template engine I wish to use.

That basically means creating a generic wrapper class that hides away the specific features of Smarty. This is the class that I usually use in my personal projects:

<?php
require_once(APP_SMARTY_PATH . "Smarty.class.php");

class Template_API
{
    var $smarty;
    var $tpl_name = "";

    function Template_API()
    {
        $this->smarty = new Smarty;
        $this->smarty->template_dir = APP_PATH . "templates/";
        $this->smarty->compile_dir = APP_PATH . "templates_c";
        $this->smarty->config_dir = '';
    }

    function setTemplate($tpl_name)
    {
        $this->tpl_name = $tpl_name;
    }

    function assign($var_name, $value = "")
    {
        if (!is_array($var_name)) {
            $this->smarty->assign($var_name, $value);
        } else {
            $this->smarty->assign($var_name);
        }
    }

    function bulkAssign($array)
    {
        while (list($key, $value) = each($array)) {
            $this->smarty->assign($key, $value);
        }
    }

    function displayTemplate()
    {
        $this->smarty->display($this->tpl_name);
    }

    function getTemplateContents()
    {
        return $this->smarty->fetch($this->tpl_name);
    }
}
?>

APP_PATH and APP_SMARTY_PATH are constants defined in a configuration file. They specify the path on the server where my scripts are stored and where the Smarty library is located, respectively. I usually like to bundle Smarty and PEAR::DB with my own applications, to prevent against problems arising if the system administrator decides to upgrade the system-wide PEAR library.

In any case, the wrapper class above allows me to have scripts that would look similar to the one below:

<?php
include_once("config.inc.php");
include_once(APP_INC_PATH . "class.template.php");

$tpl = new Template_API();
$tpl->setTemplate("example.tpl.html");

$tpl->assign("links", "list of links goes here");

$tpl->displayTemplate();
?>

APP_INC_PATH is, as you probably guessed, the path on the server where my classes are stored--my "include" directory.

You also probably noticed that the script above is totally clear of any markup or related layout logic. This is still a very simple script, but you will continue to see the same type of code when using this kind of system.

Smarty Template Engine Functions

Some of the most useful features of Smarty are in the wide variety of functions available to use in the template itself. It might seem odd to be able to use functions from inside of the templates, since the whole idea is to keep the logic separate from your layout. This is template logic however, not business logic.

I often use the html_options function. Below you will find a few simple examples of its use:

<?php
include_once("config.inc.php");
include_once(APP_INC_PATH . "class.template.php");

$tpl = new Template_API();
$tpl->setTemplate("example.tpl.html");

// first select box here
$states = array(
    "CA" => "California",
    "TX" => "Texas",
    "NY" => "New York"
);
$tpl->assign("states", $states);

// second select box here
$abbreviations = array("CA", "TX", "NY");
$titles = array("California", "Texas", "New York");
$tpl->assign(array(
    "abbreviations" => $abbreviations,
    "titles"        => $titles
));

$tpl->displayTemplate();
?>

This example builds the options straight from the associative array:

<select name="states">
  {html_options options=$states}
</select>

This example builds the options from two separate arrays of values:

<select name="other_states">
  {html_options values=$abbreviations output=$titles}
</select>

This idea is easily integrated with features available from PEAR::DB. The use of the get*() functions is very handy, and appropriate in these cases. Notice the example below:

<?php
include_once("config.inc.php");
include_once(APP_INC_PATH . "class.template.php");

$tpl = new Template_API();
$tpl->setTemplate("example.tpl.html");

include_once("DB.php");
$dbh = DB::connect("mysql://user:passwd@server/database");

$stmt = "SELECT abbrev, title FROM states";
$states = $dbhl->getAssoc($stmt);
$tpl->assign("states", $states);

$tpl->displayTemplate();
?>

That's it--instant integration between your database abstraction package and your template engine library.

Handling More Complex Result Sets

While html_options is a very convenient way to build select boxes straight from a database result set, Smarty has several other interesting features that will be valuable when using a more complex setup. It's often useful to fetch a complex database result set and pass it to the template. The following example does exactly that:

<?php
include_once("config.inc.php");
include_once(APP_INC_PATH . "class.template.php");

$tpl = new Template_API();
$tpl->setTemplate("example.tpl.html");

include_once("DB.php");
$dbh = DB::connect("mysql://user:passwd@server/database");

$stmt = "SELECT * FROM news ORDER BY news_id DESC";
$news = $dbhl->getAll($stmt, DB_FETCHMODE_ASSOC);
$tpl->assign("news", $news);

$tpl->displayTemplate();
?>

Here is the companion template:

<table>
  <tr>
    <td>ID</td>
    <td>Title</td>
    <td>Author</td>
  </tr>
  {section name="i" loop=$news}
  <tr>
    <td>{$news[i].news_id}</td>
    <td>{$news[i].news_date}</td>
    <td>{$news[i].news_title}</td>
    <td>{$news[i].news_author}</td>
  </tr>
  {/section}
</table>

The section function works like the for loop construct in PHP. A common enhancement is to show things in your templates only when a specific condition happens, like so:

<table>
  <tr>
    <td>ID</td>
    <td>Title</td>
    <td>Author</td>
  </tr>
  {section name="i" loop=$news}
  {cycle values="#CCCCCC,#999999" assign="row_color"}
  <tr bgcolor="{$row_color}">
    <td>{$news[i].news_id}</td>
    <td>{$news[i].news_date}</td>
    <td>{$news[i].news_title}</td>
    <td>{$news[i].news_author}</td>
  </tr>
  {if $smarty.section.i.last}
  <tr>
    <td colspan="4">
      Total of {$smarty.section.i.total} news entries found.
    </td>
  </tr>
  {/if}
  {sectionelse}
  <tr>
    <td colspan="4">
      No news could be found.
    </td>
  </tr>
  {/section}
</table>

This example introduced several new features:

The cycle function takes a comma-separated list of values and assigns each to the row_color variable. This produces a different row color for each loop iteration.
The $smarty reserved variable holds loop information. You can test if the current iteration is the last one by examining $smarty.section.i.last, and can get the total number of rows in the $news array of data with $smarty.section.i.total.
The sectionelse part shows different information if the $news data array is empty. You can use this to show a "There were no results found"-type message in your templates.

Separating Template Files

Like any PHP script, many applications grow so complex that it's best to separate small features into their own scripts. The same thing happens in templates. Often, it's easier to include other snippets than to duplicate the same HTML in several files.

A typical Smarty-based application might resemble:

{include file="header.tpl.html"}
{include file="ads.tpl.html"}

<!-- content goes here -l->

{include file="copyright.tpl.html"}
{include file="footer.tpl.html"}

This is very useful to make your application more modular and flexible to changes. You usually want to show the copyright notice in all pages of your web site, but you don't want it in pop-up windows or other simple pages. Moving the copyright notice to its own template can make your applications more flexible in regards to template organization.

The include template function also supports some advanced features. You can pass flags to your templates to control various output options, for example:

{include file="header.tpl.html" title="special title"}

Let's say you usually have:

<title>website name - slogan goes here</title>

In your header.tpl.html template, you could have the following:

<html>
<head>
{if $title != ""}
	<title>website name - {$title}</title>
{else}
	<title>website name - slogan goes here</title>
{/if}
</head>
<body>

That's a pretty simple example, but it shows you what kind of logic you can put in your templates.

Conclusion

I hope this article demonstrated some of the best features of integrating PEAR::DB and Smarty. Have fun and most of all, remember to read the manuals!

Joao Prado Maia is a web developer living in Houston with more than four years of experience developing web-based applications and loves learning new technologies and programming languages.

Return to the PHP DevCenter.

Comments on this article

Showing messages 1 through 33 of 33.

{cycle values="#CCCCCC,#999999" assign="row_color"}
2006-07-25 11:58:59 supandian [View]

i only need one color and that is for the most recent record. How do i do it?
Su

Too much overhead...
2005-03-07 09:20:22 gagari [View]

I have been thinking a lot in that problem of integrate PEAR::DB and SmartyTemplate. The approach of the article is interesting in terms of software engeneering, but it doesn´t consider the overhead generated in the process. I mean, when you call a "getAll()" (and similars) it iterates over the DB resource putting the results in an array. Later, when you assign that array to the template it will, again, iterate over the array to fill the data on template. In a small resultset the overhead is insignificant, but in a larger resultset you may be duplicating the execution time. Perhaps it makes sense if between the two blocks of iterations you will be making some kind of validation. However in the most of cases you just want to paste the resultset data on the template.

I am working on the idea of fetch the resultset directly on the template (maybe using the plugin engine). We could use the proxy design pattern, or something like that, to develop a class that Smarty see as a data container, but as a matter of fact it uses the resultset to retrieve data.

Would you give some ideas?

Thanks,
Iuri

Do not use smarty
2003-12-05 08:18:08 anonymous2 [View]

I am currently working on a project with smarty.

It becomes very complicated.

Not that you cannot do everything, but you have another level of indirection which complicates things.

The chain from the caller to the output becomes unnecessarily long.

Do not use any template system unless you have e.g. a big magazine which needs to change design very often.

Regards,

Klaus

Do not use smarty
2005-02-23 17:45:15 mitchenall [View]

Klaus,

It seems you have misunderstood the usefulness of template engines such as smarty. What smarty, and similar template engines, provide lets you decouple your core application logic from the presentation layer.

Making a weak statement like 'do not use any template system unless you have e.g. a big magazine which needs to change design very often.' is a ridiculous and absurd. How often do big magazines change their design? I think you'll find it's very little. In fact, if you're producing a site which changes design this often, you should be looking more at CSS, not just using template engines as this will give you more flexibility than a template engine will ever provide.

However, if your application logic is being re-used in a lot of applications, which is the case with a huge variety of websites and web applications, you can easily re-use your core code, just getting designers to change templates on a per-site basis, thus reducing costs associated with building new sites. Unless, of course, you like to rewrite all of your code for each new site you do and charge your clients accordingly. Maybe you want to keep yourself in a job by having to always write new PHP code mixed with HTML which nobody can maintain, rather than reusing previously written code and just getting the designers to work on the HTML side of things.

You comments about introducing an additional level of indirection seem also incorrect to me. Smarty decouples the presentation of data from the logic which outputs the data. This is surely a good thing. It provides a separate layer for designers and programmers to concentrate on the presentation side of website, without having to get too involved with the core logic which produced that data.

I know the arguments about template engines being just as complicated as the PHP code we'd otherwise use with HTML stuck in the middle of it, but as far as I'm concerned, template engines used correctly provide a useful additional layer which ultimately makes more code re-usable. Used incorrectly, they add a level of indirection which makes the overall application slower and harder to maintain.

One problem with this article is that the author has shown few of the benefits of using template engines such as Smarty, but in order to do so, he'd have had to write a much larger article.

Another one of your comments is also wrong as far as I'm concerned, i.e. 'The chain from the caller to the output becomes unnecessarily long.' This is utter nonsense. Used correctly, the chain between the caller and output is actually greatly shortened, and the amount of information passed from the caller script to the template is greatly lessened, especially if you make good use of custom plug-ins for outputting content which is of no concern to the calling script.

presentation logic
2003-12-01 16:06:23 anonymous2 [View]

I am just looking at trying smarty as a longtime user of FastTemplates. My complaint with fast templates is you can't nest dynamic templates, and it's slow and the most annoying thing of all is when I have to mix presentation logic with application logic. It makes for pretty ugly code and till now I had no choice.

Give the designers some credit. If they can understand CSS and html they can understand the designer aspects of smarty I think.

Question about HTML structure
2003-09-17 02:42:37 anonymous2 [View]

Hi !

I see this portion of code as a problem maybe :

<html><head>
{if $title != ""}
<title>website name - {$title}</title>
{else}
<title>website name - slogan goes here</title>
{/if}
</head><body>

Why hiding the <title> in the loop ? that will cause uncomprehension to a html editor, no ?
Could we have stuff like

<title>website name -
{if $title != ""}
{$title}
{else}
slogan goes here
{/if}
</title>

I would have done like this, but maybe I'm wrong, as I just start on Templates.

Thanks anyway for the good article

Alain (chri01@hotmail.com)

Smarty and XML
2003-08-06 04:09:59 anonymous2 [View]

I would like to see an article on creating xml with smarty, I'm trying to do that right now. I'm having problems with repeatings tag within repeating tags, it's hard to abstract this in only templates. I might need to create the tags in PHP.

I absolutely agree with author
2003-05-03 03:13:04 anonymous2 [View]

I have to say, it is very different having code snippets in HTML code and having them there not ;-) As I am not a main html editor, just a programmer and I work with HTML only when i really have to. This article is a very good example of separating logic & presentation and i think that developers at Smarty would try to find ways how to make Smarty logic in HTML more understandable or better more invisible for designers...
I appreciate the article.

Default Title
2003-05-01 09:23:22 anonymous2 [View]

I emailed this to jcpm before I saw the discussion at the bottom of the page, so I'll post my comments here. :P In the last example, instead of using {if} and {/if}, you can have just one TITLE tag that looks like this:

<title>website name - {$title|default:"slogan goes here"}</title>

I think that makes for much clean code. <shrug>

jason

What do your web pages look like!?!
2003-04-29 15:48:01 namejko [View]

In all honesty I can not believe how thick headed so many people can be! Anyone who thinks that there should be NO PRESENTATION logic in a template file must have a website that is either impossible to update or looks like something designed back in the early 80's!

With all of the formatting options now available in HTML code, it is almost just as impossible for a programmer to develop HTML code in the "business logic" portion within PHP. A simple example that can extend the row color altering in a table would be one in which a website moves to using different fonts through either font tags or stylesheets. Are you telling me that when the design team decides to add CSS to the fonts in SOME of its tables, it is the programmer's job to go back to EVERY piece of code that involves the outputting a table string and adding that code in ONLY where the design team wants it!?! (before anyone says anything, I understand that you could abstract this somewhat. But like I said...if only a couple of tables are meant to be formatted a certain way, and those tables were all generated using the same abstracted makeTable() code, the development team would need make additional functions with similar code where the ONLY difference is some CSS tags).

Ultimately, I can't see why designers should not learn minor programming constructs any more than programmers should learn HTML. It is a team effort, but the simple truth is that a designer who learns some Smarty code could make a MUCH nicer web page than a programmer who learns HTML code. Why can't people understand that. Wow!

Adam

Article shows poor understanding of Smarty & pear
2003-04-23 15:13:42 anonymous2 [View]

There are many code examples in this article which are done the wrong way when working with smarty. Here's some of them and the correct code:

1. subclass Template_API is totally useless. The functions defined in this subclass are dupliacats of existing smarty functions. Instead, the author should have created a smarty object and set the template, compile and config dirs in code rather than in the constructor.

1a. setTemplate: this function is not necessay. This seems to be a carry-over from phplib type templates where the template engine had to know something about the template before parsing it. Smarty doesn't need to know anything about the template before parsing therefore the smarty function display() is used at the end of a script.

1b. assign & bulk assign: the smarty function assign() can take an associative array of key=>value pairs and assign them. The inclusing of both of these functions is unnecessary.

2. This code:
include_once("config.inc.php");
include_once(APP_INC_PATH . "class.template.php");
should NOT be needed for every page. Instead, the config.inc.php should require_once the class.template.php so the duplicate include in every file would be unnecessary.

3. This code:
include_once("DB.php");
$dbh = DB::connect("mysql://user:passwd@server/database");
is a horrible practice. By putting your userid and password and connection info to your database in every script, you are creating a maintenance nightmare. This should be done in the config.inc.php file.

4. This code:
$news = $dbhl->getAll($stmt, DB_FETCHMODE_ASSOC);
should not include DB_FETCHMODE_ASSOC. Ideal php applications should be designed to use the same fetchmode on every page so the best practice would be to create the db object in config.inc.php and call
$dbhl->setFetchMode(DB_FETCHMODE_ASSOC);
then the call in the page would be:
$dbhl->getAll($stmt);

5. As another person pointed out in these notes, the use of foreach is prefered over sections. foreach is a newer than section....the author may not be up to speed on the latest smarty versions.

Tom Anderson
My own article on the use of pear & smarty:
http://smarty.incutio.com/?page=SmartestSmartyPractices

No, it does not (rebutal)
2003-04-23 19:55:28 jcpm [View]

1. Did you read what I said about the Template_API class ? I only create it so I don't have to set all of the appropriate variables and to give me an extra taste of security in thinking that I could use the same front-end code with different templating engines.

2. I understand what you are trying to say, but the include is necessary because there will be cases where some pages / scripts in your web application will not need the template class. Instead of having to parse the Template_API class, and the Smarty classes on every page hit, putting it on a page by page basis helps in performance a little bit.

3. Please, let's not over-react here. It was just supposed to be a simple example, not a best-practice type of article. It would be a very long article if I needed to describe and show all helper functions and includes that I usually use for simple examples like the one you are talking about here.

4. Why are ideal PHP applications supposed to use the same fetchmode on every page ? I know the trick of using the setFetchMode() method but I don't want to lose the flexibility of being able to specify a different one when I need to / want to.

5. I'm totally up to speed with the latest versions of Smarty, but why is the use of {foreach} prefered over {section} ? There is no difference in functionality. I personally prefer to use {section} but as I said to the other poster, that is just a personal opinion. Similar to the use of 'foreach' or 'for' in PHP, may I say so.

Cheers,
Joao Prado Maia

No, it does not (rebutal)
2003-04-24 09:06:48 anonymous2 [View]

Not trying to flame, just a discussion. With that said:

1. K, I probably didn't read your article close enough when you explained the why of it. I personally don't plan on ever using anything besides smarty, hence I thought it was unnecessary. I still do think it's unnecessary, though. For this article, you're reviewing pear & smarty; for this reason I think the use of the extra class for non-smarty template engines is unnecessary...if the article had a broader scope to include other engines (I'm very glad it doesn't), I could see the justification for the class.

2. My personal experience has shown that the number of pages that do NOT require database access in a complicated php application is nearly zero. Because the exception is rare, I prefer to set a global variable if db access will not be necessary. So, for the config.inc.php:

if (!$_GLOBALS['_skip_db']) require_once 'db.class.php';

Then, all pages that need db access have:

require_once 'config.inc.php';

as their first line and the rare page that does not need db access has:

$_GLOBALS['_skip_db'] = true;
require_once 'config.inc.php';

3. From your reply: "It was just supposed to be a simple example, not a best-practice type of article" but from the article "...I will show throughout this article my experiences and best practices in integrating these two amazing libraries."
This is the reason I pointed out the db connection info in each script...the article did mention best practices.

4. IMHO, ideal php applications should use the same fetchmode throughout so maintenance is easier. If you can work on any page in an application and know that it's using an ASSOC fetch mode, you will save a lot of time. Also, if an application does not use the same fetch mode globally than you will need to spend extra time on every edit to check the fetch mode. Personally, I try to code all my applications in such a way that the next person to edit them won't hate me. I think application-wide standards for things like fetch modes is a good way to do that.

5. The syntax for section is not as clean as foreach. It does has some features which foreach does not, but, for basic use, foreach will save you a lot of typing (e.g. foreach does not require you to name the iterator when specifying a specific value in the current loop).

Later,
Tom

No, it does not (rebutal)
2005-02-23 17:15:27 mitchenall [View]

5. I agree... the section tag is the wrong thing to use in this instance. It's confusing to both designers and future template maintainers and doesn't serve any good purpose in the example given as far as I can tell.

This is not separating logic from presentation
2003-04-22 22:22:07 anonymous2 [View]

When you still have logic expressions in the HTML, this is not separating logic from presentation.

If you ask most HTML designers that do not understand your HTML templates because they still have programming logic in them.

This is a thing that usually developers that work alone have like the article author do not understand because they are used to do both the programming and the presentation design.

This is not separating logic from presentation
2003-04-23 19:59:26 jcpm [View]

As I said in the article, presentation logic is very different from business logic. I see nothing wrong with allowing the designer or programmer to separate the logic in which a row gets a different color, for instance.

From personal experience, having presentation logic in the PHP code eventually gets confusing and messy. Why should I have to loop through blocks as it is done in PHPLIB just to set a placeholder to have the color #CCCCCC or #999999.

But most of all, this is personal opinion. Templating systems should be chosen by what you feel comfortable using, and some people may prefer Smarty and some people may prefer PHPLIB or some other system.

Cheers,
Joao Prado Maia

This is not separating logic from presentation
2003-04-25 00:55:18 anonymous2 [View]

The problem is not in the template engines but in the way programmer use them.

The presented example is very clear that in the end it will always be the same person doing the presentation and the logic. This means that if you want to alter the logic, you need to alter the presentation templates.

Consequently, it will be more expensive to companies that work that way because it has all to be done by a single person that needs to know 3 languages: PHP, HTML and the template engine language.

For people that deal with that, it may be just fine, but people with that many qualifications are harder to find, charge more and stall the development more because all the work is dependent on them.

Bottom line, messing three languages to use a template engine is a very inneficient and expensive way of work. Only people that work alone have an hard time understanding this.

This is not separating logic from presentation
2003-07-29 02:26:04 anonymous2 [View]

>This means that if you want to alter the logic, you need to alter the presentation templates.
Not true. You still do not see the difference between the two logics involved. when you do a script that needs a template you write the code on the script, then you pass the needed vars to smarty. if you change the original code as much as to have the necessity of changing the logic on the template is your own fault - that may occur because you didn�t thought well of the use of that script.
anyway, let�s say that your boss says you "ok, now change it because I'm a big kick4ss". you have to change the script and the template. but you would also need to do it if you embed the html on the script making the task much harder.
@about template syntax for html coders
if you know to code on HTML you certainly can understand how to use {if (something)}foo{/if} or maybe {section loop...}. that two functions, plus literal and comments {* are the most I use. I think that it is not precissely about learning assembler...
.:c0p0n:.

This is not separating logic from presentation
2003-04-23 10:09:22 anonymous2 [View]

There is more than one type of logic. The idea behind templates is to remove business logic from your presentation. Not to remove presentation logic from your presentation. There is a bunch of logic that has every right to be in the templates - such as alternating table row colors, theme selection, special messages, etc. This has nothing to do with the business logic or data access. Try this:

http://www.massassi.com/php/template_engines/

This is not separating logic from presentation
2003-04-23 17:18:23 anonymous2 [View]

No, you are not getting the point. Any logic flow control should not be in the templates because this simply rules out that majority of the real presentation designers.

If you need to iterate over the same template, like in alternating table row colors, just do it in the programming. That is what programming is meant to be, control the program output logic flow.

Template engines like Smarty that make you handle any logic in the templates are not a great improvement over the traditional PHP programming. They require you to learn a third language that is neither PHP nor HTML.

Properly conceived templates should only contain HTML, placeholders and delimiters, so they can be edited in any HTML editor and any good graphic designer can do his job and not have to learn that third language.

This is not separating logic from presentation
2003-05-06 04:32:20 anonymous2 [View]

Well, you're right when you say:

If you need to iterate over the same template, like in alternating table row colors, just do it in the programming. That is what programming is meant to be, control the program output logic flow.

However, how should the programmer know which color to iterate over and how to specify it? It's the HTML designers job to say "use color a and b". The programmer tells the designer that this row will be repeated for an unknown number of times and then the HTML designer has to come up with a good representation.

I don't see what's wrong with this.

This is not separating logic from presentation
2003-04-24 09:14:15 anonymous2 [View]

>> Any logic flow control should not be in the templates...

I felt exactly the same way for a very long time. I had heard of smarty for months before I ever actually tried it. I didn't like it. Putting looping constructs inside a html file! WTF?!

However, I decided to just try it because of all the rave reviews I had seen and I'll never go back.

Trying to wrap my head around the fact that there is 'code' in the html was tough. This method was as bassackwards as I could imagine. I stuck with it though...I just made some example pages to become familiar with it then I modified some existing pages from phplib to smarty and WOW. The ease of editing the smarty pages and the power available in smarty changed how I've programed every php application since.

So, my advice is to try it out. It may not be for you....I didn't think it was for me, but damn was I wrong.

Tom

This is not separating logic from presentation
2003-06-05 12:40:35 anonymous2 [View]

I totally agree.

I needed a way to seperate the presentation data and logic from the business logic... since someone else will be editing the html after I am done with the code.

I thought of simply printing the HTML myself and allowing them to change it via CSS. However, this proved to be cumbersome. It allowed them to only change the look of components, and not change the components themselves... plus the CSS files were getting to be too big.

So I read an article on slashdot.org yesterday about seperating business logic and presentation. One of the comments linked to this article as well as the Smarty site. I was a bit skeptical.. thinking I would probably just write my own template engine. However, I gave Smarty a shot after reading this article, as it seemed very easy to use and very easy to learn (face it, for an experienced programmer, the "language" takes 2 seconds to learn). I LOVE it so far. It has made me feel so much better about writing my code and not worrying about the presentation. It will be easier for the guy who I'm writing this for to manage.. he does know some programming, so it's not like the templates will baffle him.

I appreciate this article and wholy recommend Smarty to anyone to wants a good templating engine with some power. Given that speed isnt critical that is.

This is not separating logic from presentation
2003-07-10 00:18:36 anonymous2 [View]

I agree too.
As a graphic designer, Smarty seems very good solution for templating. The good point of Smarty is that, when the designer wants to change a color or any visual aspect of presentation, he can do it without asking to programmer, without touching to any program code.

Actually I work for a web site with PHPLIB. I have to switch between template files and php codes in order to change/preview/confirm and I'm sure if, after my changes in the php code, everything goes still fine in the business logic side...

a cleaner looping syntax
2003-04-22 06:50:26 anonymous2 [View]

FWIW for looping through arrays in Smarty templates I prefer this syntax, which is a bit more readable:

{foreach from=$widgets item=widget}
{$widget.name} : {$widget.price}

{/foreach}

I enjoyed the tricks relating to bulk assignment of template variables.

a cleaner looping syntax (or is it?)
2003-04-23 19:46:25 jcpm [View]

I guess it's a matter of personal option to say that the {foreach} syntax is more readable than the {section} one.

I personally prefer the {section} one, and that is why I use it all over this article.

Cheers,
Joao Prado Maia

Um...
2003-04-21 11:52:41 anonymous2 [View]

People's comments about smarty's speed are misleading. If you look at smarty's benchmarks (the ones they programmed), smarty falls somewhere in the middle of the road. If you want speed, smarty simply is not the way to go. It takes an extreme amount of time for php to interpret the huge classes included (which are required EVEN IF the template has already been "compiled" - which seems to make the compiling step pretty pointless). Check their benchmarks, you may be surprised (and those are even with a php script caching solution like phpAccelerator - if you aren't using one, seriously reconsider using smarty).

Um...
2003-04-23 20:04:59 jcpm [View]

But in other systems the 'huge' template related classes are also interpreted. I mean, a PHPLIB based template still needs to parse and execute the main Template class every time it needs to parse and output a template file.

If Smarty can compile the template file into an actual PHP script, wouldn't you agree that it basically skips one step of the normal process of the 'parse/set variables/output parsed template' chain of events ?

Cheers,
Joao Prado Maia

Good code bad article
2003-04-18 09:17:12 anonymous2 [View]

The author assumes we all know what Pear::DB and Smarty are. I've been programming for 20 years and doing PHP for 4 and I didn't know about Smarty. I still don't. A short paragraph on each would have clued those of us who didn't know in while not alienating those who did. I'm suprised O'Reilly let this crap through. They usually have higher standards.

Good code bad article
2003-06-05 08:17:35 anonymous2 [View]

How can one take 4(!) years of php programming without ever taking notice of smarty? You must be sitting in a real dark, dull cave. some people need 20 years for things others do in 5, because they are simply trying to do things they never should...

Good code bad article
2003-10-19 15:16:30 anonymous2 [View]

well, could any one tell me what for i need this smarty if i alrady have php? what can give smarty to me except caching? why i must learn other scripting language if i could call some thing like this :<html> ... <?include("othe.inc")?> <?=my_func("params"...)?> ... <?=$myvar?> <?include("footer.inc")?> ...

Good code bad article
2003-04-18 11:06:44 jcpm [View]

Thanks for the feedback on the article. You are right about giving a little bit of background in what PEAR::DB and Smarty are - we will add a new introductory paragraph in a bit.

You may also want to look at a previous article about Smarty that got published here:

Introducing Smarty: A PHP Template Engine - http://www.onlamp.com/pub/a/php/2002/09/05/smarty.html

Cheers,
Joao Prado Maia

P.S.: In the future please tone down your comments. While you are right about needing some introduction about these technologies, my work is certainly not "crap".

Assuming Too Much
2003-04-18 10:44:22 chromatic | [View]

You're right; I thought it was more obvious from the context than it is. We'll add a short paragraph of explanation.

Thanks for the idea!

View All RSS Feeds >

800-889-8969 or 707-827-7019
Monday-Friday 7:30am-5pm PT
©2011, O'Reilly Media, Inc.
All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners.