Before doing that, allow me to make a premise.

Back in the old days, we could copy our site structure as many times as the number of languages we had to work on, go deep into the pages and make necessary changes.

This worked well enough for static content, but had its downsides:

• There were problems updating content
• If you wanted to send the text to a translation service, you had to pull it from the pages yourself
• When the text came back from the translator, you had to work again to insert it into the pages
• There isn't a standard way to format the text and many translation services don't understand HTML, so you had to exchange Word documents and manually convert the text into HTML again to preserve code cleaniness
• There are problems with foreign character sets, you have to translate the HTML entities or convert between encodings
• The first page on your site was nothing more than a list of languages and flags, that meant the first and most important page of all the site has no content
• If you made a guess choosing your first page language, your other languages had to be manually selected by the user to make the switch.
• If you positioned certain elements into the text, you had to insert them manually again when you put the new content.
• There was no way for the translators to make the changes their selves without asking the webmaster, if they had not basic design skills.
• If they claimed such skills, you had to trust them enough to give them access the site source files and have faith in the fact they will not screw up anything.

The list can go on forever. Guess what? Dynamic websites are even worse! The problem is that most of the programmers build up websites pulling data from an archive (text files, a database connection, a service on the Intertubes) and put this materials into template pages. When preparing or upgrading a site to be multilanguage, you had to have a way to pull different data from database for each idiom. Then you have to figure out how to translate the text into the templates.

There are many ways to solve these problems.

You could manually change all the tables to hold the data for all idioms, and prepare a very big array that holds the strings you put into the template, put this big array in different files, one array for each language, and include the files as the user switches language.

This would be only the beginning, because then you should mantain all these arrays in sync. If you wanted to change this data from a control panel you have to put all the strings in a database. Manage language fallbacks (what if a string is not translated in a language?). What about caching? Then you had to write the procedures for querying, inserting and modifying such data.

Meet Translation2, the Pear module that does all of this for us, and much more. After installing it from the repository, we initialize it using this code:

require_once 'Translation2.php';

$tr =& Translation2::factory('mdb2',$db, array(
'langs_avail_table'        => 'translation_langs',
'lang_id_col'            => 'id',
'lang_name_col'            => 'name',
'lang_meta_col'            => 'meta',
'lang_errmsg_col'        => 'error_text',
'lang_encoding_col'        => 'encoding',
'strings_default_table'    => 'translation_strings', 
'string_id_col'            => 'ID', 
'string_page_id_col'    => 'page_id', 
'string_text_col'        => '%s', 
'autoCleanCache'        => true 
) );

Translation2 uses MDB2 as an archive foundation, so you have either to create a MDB2 connection, or reuse an existing one by passing the database object. As I presume you already use a database connection, I'll skip this part. Let's assume the database object is called $db.

Next we pass an array of parameters, specifying the gory details of the tables holding out our translation data. The example depicts two tables, translation_langs (that lists all languages) and translation_strings (that contains all the text).

The table that holds all the languages needs a column for the language id (like for example 'it' or 'en' or 'fr'), name (like 'English', or 'Espanol', 'Italiano',' 'Francais'), meta (extended name, like 'American English', usually matches the name), error text (when the string is not translated, for example 'not available','non disponibile','non traduit') and encoding ('iso-8859-1','utf-8' and so on). You can call these columns and tables as you want, you just need to pass the names into the parameters array.

The strings table instead has an ID column (I put there an MD5 hash of the strings I want to be translated, but any text will do), the page ID column (so you separate and query strings for different pages), the text column for each language ('%s' in the example means the columns are called after the language ID) and any other parameter you wish to use.

To set the language ID and page ID, simply issue these two commands:

$tr->setLang("it");
$tr->setPageID("LOGIN_PAGE");

You then start to initialize the so called 'decorators', additional features of the translation system. The most useful ones are the Cache decorator (that uses the Cache Lite Pear module) and the fallback decorator (to provide fallback strings in other languages).

An initialization sample of the Cache decorator follows:

require_once "Cache/Lite.php"; 
$tr =& $tr->getDecorator 'CacheLiteFunction'); 
$tr->setOption('cacheDir', '/cache/lang/'); 
$tr->setOption('lifeTime', 3600);

with getDecorator you call the decorator. As you see we had to require the cache module file. Then we set the options: the time the system has to cache strings and the directory to use for caching. There are other options, feel free to explore.

The fallback system is even easier:

$tr =& $tr->getDecorator('Lang');
$tr->setOption('fallbackLang', 'en');
$tr->setOption('fallbackLang', 'it');

that means "if you can't find the string in the chosen language, fall back to english. If there isn't an english string, fall back to italian". You can cascade languages as you wish. The function works on a string level, so you can have a complete translated website with only a pair of strings defaulted to another language.

To do queries you use commands like:

$tr->get('PLEASE_LOGIN');

to ask for a translated string,

$tr->getRaw('PLEASE_LOGIN','LOGIN_PAGE');

to ask all translations for a string specifying the Page ID,

$tr->getLangs();

to enumerate all languages, and so on.

You can at this point insert data into the tables yourself, or use the handy administration API that the translation system exposes. Simply initialize it (the parameters array is the same):

$tr_admin = &Translation2_Admin::factory([...continue the same way as the Translation2 constructor...]);

Then you can issue commands like:

$tr_admin ->cleanCache();

to clean the cache

$tr_admin->add("PLEASE_LOGIN', 'LOGIN_PAGE', array("en"=>"Please insert your user name and password in the fields","it"=>"Prego inserire il tuo nome utente e password"));

to insert a new string into the database.

The API enables to easily add, modify and remove languages and strings.

If you want, Translation2 can use as a data source even an XML file or Gettext GNU .po / .mo compiled files. The decorators can also be used to convert between encodings.

That's all, folks!

I hope you liked the article, stay tuned for the next episode of Web localization in PHP: language detection by subscribing to the RSS feed.

I would also be happy to answer to any questions you could have on the Translation2 module. In particular, I've tightly integrated it into a Markdown parser (a PHPBB code like language) and some plugins to provide realtime translations into Smarty templates.

On Windows, instead, there is a layer called Open Database Connectivity (ODBC) that translates the calls from the software to the database, providing a common interface and emulating missing features. Each vendor provides a specific driver, that plugs into the architecture. Via ODBC even a text file or an Excel spreadsheet can be connected and queried like it was a database.

It has been natural to me to start searching the net for a PHP equivalent of that layer. Shortly after starting I found the de facto standard for database abstraction in PHP, called MDB2. Even if it has not the flexibility of a real ODBC layer, it's lack of complexity made it very popular among fellow web programmers at first, just to find out it's ability to grow via extensions and performing in a relatively easy way a set of very powerful and demanding operations.

MDB2 is a Pear library, so you need to follow a procedure to install it. Refer to the Pear website for details.

Just after including the MDB2 scripts into your PHP file

<?

require_once ("MDB2.php");

?>

you need to  create an instance of the database class, like this

<?

$dsn = "your database type://your user name:your password@your server/your database name";

$db = MDB2::factory($dsn);

?>

so you have a connection string that explains how to connect to the database, and an object with multiple methods to perform database operations. You don't need to know other details about the database apart from the ones you put in the Data Source Name (DSN), everything else is handled by the MDB2 object.

After that, you perform vendor agnostic queries like this

$result = $db->queryAll ($sql);

But, as said, the real power behind MDB2 is it's extensions system, for example

$db->loadModule('Extended');

$tablename = "customers";

$data = array("name"=>"Bob","surname"=>"Michael");

$result= $db->extended->autoExecute($tablename,$data, MDB2_AUTOQUERY_INSERT);

I've effectively inserted a new customer into my table without writing a single word of SQL, and without worrying of the actual table structure.

The same applies to interrogation queries, like this

$tablename = "customers";

$where = "`NAME` = 'BOB' AND `SURNAME` = 'MICHAEL'";

$result= $db->extended->autoExecute($tablename,null,
MDB2_AUTOQUERY_SELECT,
$where,null,true,true);

the only SQL here is the where clause, everything else is managed by the library.

You can even store an XML backup of your entire database with a few commands

$db_schema_options = array(
'use_transactions' => true,
'log_line_break' => '<br>',
'idxname_format' => '%s',
'debug' => true,
'quote_identifier' => true,
'force_defaults' => true,
'portability' => true
);

$schema = MDB2_Schema::factory($dsn, $db_schema_options);

$definition = $schema->getDefinitionFromDatabase();

$schema_dump = $schema->dumpDatabase($definition, array(
'output_mode' => 'file',
'output' => $dumpfile
), MDB2_SCHEMA_DUMP_ALL);

where $dumpfile is the file name you want your backup to go to.

The notion of schemas enables your application to seamless update the database across updates. The MDB2 can made automatic modifications of your table definitions to match the ones into the schema.

The library enables to use complex database functions, like transactions, to make your web applications secure and overcome stability problems when delicate procedures are performed, like the cart checkout on a e-commerce website, a money transfer, or any other situation where a power outage or a software interruption can lead to an partial update. Transactions group the operations so that any error will lead to a rollback, preserving the state your data was prior to updating.

If later in the process you want to change your database, for example from MySQL to Microsoft SQL server? Simply change your DSN from mysql to mssql and you are ready!

Did you like this article? Subscribe to my transactional feeds and leave a comment!

As always, let's use an example

function startslideshow() {

dosomething();

};

window.onload="startslideshow";

This makes the function startslideshow (an example used through the article) execute when the window loads. But what happens if another function wants to execute on window load too? If you added, later in the chain of scripts, the code

window.onload="startanotherthing";

the other function gets executed, but replaces the first one.

The same happens if you use this code

<body onload="startslideshow()">

That means the function startslideshow will be executed after the body of the document has loaded.

If you instead write this code

function startslideshow() {

dosomething();

};

startslideshow();

You'll have a timing problem, because when executing startslideshow(), you will not be sure that the HTML of the page is completely loaded and available to the script. Don't even think using a setTimeout and try to guess how much time it takes. It would be a so bad solution police would come to your home and arrest you for 'bad programming'.

So, you are faced with these two problems:

• You need the code to execute when the page loads
• You need the code to be self encapsulated, so you can plug and play it in the page without worrying it will disturb other code

Nothing else? Indeed, there is more. If you execute the code on page loads, it means all of the page should be downloaded, even all the images. If you have a slideshow, and the user clicks on an image before all the others on the page are loaded, you will have problems because your initial function has not executed yet.

Enter the realm of DOMready. Many experienced programmers now let their code execute not when the entire page has loaded, but only when the Document Object Model (DOM) is ready, that is, all the HTML and javascript files have been loaded and are available to the JavaScript interpreter. The DOMready event fires way earlier during page rendering.

Unfortunately, the DOMready event is not very easily approachable, as browsers have slightly different implementation of the technique.

Chances are you already use a JavaScript framework to address cross browser incompatibilities.

If you use prototype.js, probably you access the window load event with this code

Event.observe(window, 'load', startslideshow);

replace startslideshow with your function. You can chain more Event.observe and prototype.js will take care by itself of executing the functions one after the other on window load.

To access the earlier, faster DOMready event, replace that code with

document.observe("dom:loaded",startslideshow);

the function is brand new and requires a version of prototype.js not lower than 1.6 .

What if you use jQuery? The code is

$(document).ready(startslideshow);

That's all. Indeed, the code is not faster di per se, just the perception of responsiveness of the page is, because the code gets executed earlier.

If you use the debugger plugin Firebug for Firefox, in the Net panel of the latest version there are two vertical lines drawn. The first one detects the point in time the DOM is ready. The second one when the page is loaded.

The only things you're left to do is subscribe to my feeds and leave a comment if you liked the article, and... happy coding!

This is the plan I've found effective enough to overcome management problems. Before starting, remember to keep each meeting one hour only, and no more than a meeting a week with the same client.

The initial briefing, that is from one to three meetings with the client, so you can hear their idea and sketch up a concept. After the first meeting, you produce at least two proposals, with time and compensation. Try not to talk, but to hear. The client has not chosen you, not yet. So any information disclosed now, will be passed to your competitor. Include any hidden costs, like hosting, copywriting, design and maintenance, like changes, updates and SEO. Be sure to be crystal clear about all costs after the project goes live.

As the customer agrees on a proposal, you produce a project, where you list any and all the feature of the web site. It's better to keep this document simple, as it doesn't force you to omit functions. It states the functions the project will end with, regardless of the path chosen. It's basically a guarantee to the client.

Accompanied to the project comes the standard contract. Do some research, and try to explore all the possibilities, protecting yourself in a reasonable way. In the contract you mention the project as an attachment. Have your contract perfected by a lawyer.

Contract signage comes with a payment by the client. As a contract is a deal, you are obliged to respect your part of the deal, so should the client.

The day after the agreement, look for the tasks the client should accomplish, that is a list of categories for an online store, the list of products with relative prices to put online, pieces of text regarding company presentation, and so on. Many times, the customer is the slowest of all the actors involved, so have him/her busy from day one.

Start producing paper sketches on the product, it's time to be creative. Don't let the computer in your way, it will probably only slow you down. Take a bloc notes with you, and if you manage multiple projects, put the name of the relative project, the date and the title,on top of each sheet.

At this stage, turn on the computer and start researching for user interface patterns on the web. That is, look at login forms, search boxes, product details pages, lightboxes, carousels, footers. Try to analyze which of these make a better user experience (the so called UX), faster, easier, more complete, responsive and enjoyable.

Using a mindmapping software, produce a complete sitemap. I prefer Conceptdraw Mindmap. Don't leave out important service pages, like the login, register, password retrieval, legal and privacy information, the contact form. Make a meeting with the client and change the sitemap if needed. The map can be made of multiple sheets, so, for example on the second sheet you can list all the categories of an e-catalog, and list a single category page on the first sheet.

Open a prototyping program, like Axure RP, and start drawing the wireframe of your application. Try to go deep into the interations. If you're producing an e-commerce website, you should be able to actually see a product put into the cart and the entire checkout process, for example. Have another meeting with the client, have him/her check out the HTML prototype, make the suggested modifications. Let the program autogenerate a specification document (the spec).

Attach a print of your complete sitemap and specification document to a document with the date, have the client sign it for approval. This makes a milestone, you cannot go back on already done work without the client paying more.

Give the same documents to the designer, or if you do the design yourself or are the designer, it's time to fire up your graphic program.

While you wait for the graphics to be done, the same applies to the developer. If you are the same person, better have the graphics before start coding.

When the graphics are done and from time to time, call the client and ask for any task he/she had to do, that is, any material he/she had to produce, and that you asked from day one. Have a meeting, review the graphic design with the client, make the suggested modifications. If you're the graphic designer, send the modifications to the developer.

Print the design and any material produced, attach to a document with the date, have the client sign it. Ask for a part of the payment of the entire web site. This is another milestone, also you should have about 50% of all the money now, and half of all the work done, confirmed by the client, so you can't go back.

If you're the developer, start chopping the design into HTML. Refer to the prototype and the specs, there should be all the material and design elements to complete each interation, you only need to focus on programming. Use a test server. By the way, use progressive enhancement, make sure everything works without javascript, then start leveraging the interface. Make sure to complete the administration control panel.

Show the site to the customer, on the test server. Make note of the modifications he/she asks for, agree on the price and factuality of any changes after the steps above.

Do the modifications as fast as possible, to dodge the possibility of the client changing his/her mind and looking for more changes. Ask for a payment, you should have three quarters of the sum now.

Leave the site on the test server. The client should be able to look at the work done live. Start testing, look for inconsistencies between browsers. It's not possible to produce modifications anymore at this stage. Produce training documentation on the administration of the site. I prefer Techsmith Camtasia because you can a record a screencast, instead of writing pages and pages of documentation.

If the site is closed source and the contract permits this, encrypt the source code. Make a DVD with the source code, the graphics, all the documents and the screencasts, compressed in ZIP form with a password.

Ask the client for the last payment. After you're sure you received the payment, put the site live, and send or give the client the DVD. Store the DVD, paired with another one with any any intermediate material used for future changes, and unencrypted source code.

Repeat again and again.

Have you got any comments or questions?

Managing even a small project, however, requires some planning beforehand, to overcome some series of unfortunate events that may happen.

Some of these events are your fault: you're late on schedule, don't test your web site thoroughly, lose interest over time on the job.

Some others are the client's fault: they want to change things when it's too late, they don't pay in time or don't pay at all, demand exhausting meetings over details you're not even supposed to know.

Then come the partners fault: if you are a developer, chances are you prefer to team up with a graphic designer, who produce wonderful website designs, but clunky and unusable, with large visual content and maybe almost no text at all. If you are a graphic designer, you strive to push a really good product, but your developer chops it up and it becomes butt ugly, you need to design new parts of the site and redraw some others.

There come the technical problems, like bugs, incompatibilities between browsers, the control panel doesn't work, the client tests the site on a Windows 2000 or older computer full of viruses and spyware, with Internet Explorer 5 on it on a 640k DSL connection shared with two hundred other people downloading from emule (I'm not kidding).

You only want to do the thing you like best, that is coding or drawing beautiful and standard compliant websites.

Each of these reiterations has other disadvantages, I call them task serialization and latency.

Each piece of work depends on others pieces, and without planning, much of the time you or others sit idle trough all the project time because other people need to do something. You thought having more people meant reducing the time by dividing it, but the work that can be done in parallel, that means in the same timeframe by more than one person, is not that much.

The task latency means a one hour task will get done in two weeks, just because of a missed telephone call or holidays or contingencies.

Sometimes the client wants to save money by writing his own copy or doing the graphics itself. 80% of the time, the customer doesn't provide the requested work in promised time, and if he/she does it, it's sub par with the rest of the project, as it is done unprofessionally.

At the end of this mess, you have all your materials and open up Dreamweaver or notepad or your choice of HTML editor, starting as fast as you can to redraw and rewrite parts upon parts of your initial work, because the customer threats to sue you or abandon the project if it is not done in a timely fashion.

The code and graphics you do, at this point, are not accurate and perfect, as the pressure of the work is too much and you simply don't have time to apply the finishes. Testing is reduced to minimum, and many bugfixes are solved by applying patches over code. You even find yourself making decisions outside your area of expertise, like if you are the developer on color, aspect and position of elements, because it would take too much time if asked to the designer to do. You're a designer, but you start writing the text materials to fill in the voids.

Next article I'll provide useful information on how to solve these common problems.

Do you recognize some situations that happened to you? I would be happy to receive comments.

It is extremely useful if you want to:

• Organize all your bookmarks in a useful way
• Have a link under the attention of a friend or coworker
• Discover new links by looking at what other people are bookmarking
• Assign a link the collective tags, so you don't have to write them yourself
• Have a network of friends, whose links are more relevant for your activies.
• Add a person's feed to your RSS reader

How to access to all this information goodness? You start from the del.icio.us homepage, create a free account by clicking on "get started". Fill the form and you are ready to go.
Now, you can add your links from the del.icio.us website, or by using a third party tool. The service itself promotes an extension for Firefox, but I suggest to use the one provided by Yahoo! Inc. because it is more feature complete.
Upon installation, the extension starts to import all your existing bookmarks into your del.icio.us account, automatically tagging them. Let it be and wait for a pair of minutes. Next operation in line is to hide your existing bookmarks interface to use only the del.icio.us one. On the upper part of the Firefox windows you'll notice, amongst others, a del.icio.us menu. From there, the last voice is 'Hide bookmarks menu'. Now you can add a bookmark clicking the 'tag' icon or by pressing CTRL+D, browse bookmarks clicking the 'search your bookmarks' icon or by pressing CTRL+B, or do the same actions from the menu.
When you add a bookmark, a new window will appear, with Recommended, Network and Popular tags.
Clicking on these words will tag the link, the recommended tags are from your existing link library, while I sometimes find the popular ones to be more fitting. If you are unsure, better more than less, you can refine these later. If nobody has the link in his del.icio.us (this means you're the first to discover this resource, in the network) you have to manually add the tags. Remember, tags are separated by spaces, so you can't write for example 'web 2.0', but 'web2.0', not 'New York' but 'NewYork'.
To exchange links with your friends (they should have a del.icio.us account too) simply click on the Network tags of your friends. When you're ready, you press 'Save' and the bookmark will be saved.
Adding a friend is done by going on your friend del.icio.us site, then clicking on the link 'add ... to your network'. Many blogs (like this) have ready made links to add an article to del.icio.us (if you don't have the extension installed) and even add a person to your network (like my Add me to your network link).
To check the links inbox, from the del.icio.us menu, choose del.icio.us website, then Links for you. Be sure to have a look to Popular and Recent bookmarks, there are very interesting things there. Nearly all the pages can be formatted as RSS feeds to use in your favourite aggregator.

To use these new transitions, the easiest way is to open the effects.js file inside the src folder of your scriptaculous library, and add these lines at the end:

/*
transitions.js

Based on Easing Equations v2.0
(c) 2003 Robert Penner, all rights reserved.
This work is subject to the terms in http://www.robertpenner.com/easing_terms_of_use.html

Adapted for Scriptaculous by Ken Snyder (kendsnyder ~at~ gmail ~dot~ com) June 2006
*/

/*
Overshooting Transitions
*/
// Elastic (adapted from "EaseOutElastic")
Effect.Transitions.Elastic = function(pos) {
return -1*Math.pow(4,-8*pos) * Math.sin((pos*6-1)*(2*Math.PI)/2) + 1;
};
// SwingFromTo (adapted from "BackEaseInOut")
Effect.Transitions.SwingFromTo = function(pos) {
var s = 1.70158;
if ((pos/=0.5) < 1) return 0.5*(pos*pos*(((s*=(1.525))+1)*pos - s));
return 0.5*((pos-=2)*pos*(((s*=(1.525))+1)*pos + s) + 2);
};
// SwingFrom (adapted from "BackEaseIn")
Effect.Transitions.SwingFrom = function(pos) {
var s = 1.70158;
return pos*pos*((s+1)*pos - s);
};
// SwingTo (adapted from "BackEaseOut")
Effect.Transitions.SwingTo = function(pos) {
var s = 1.70158;
return (pos-=1)*pos*((s+1)*pos + s) + 1;
};

/*
Bouncing Transitions
*/
// Bounce (adapted from "EaseOutBounce")
Effect.Transitions.Bounce = function(pos) {
if (pos < (1/2.75)) {
return (7.5625*pos*pos);
} else if (pos < (2/2.75)) {
return (7.5625*(pos-=(1.5/2.75))*pos + .75);
} else if (pos < (2.5/2.75)) {
return (7.5625*(pos-=(2.25/2.75))*pos + .9375);
} else {
return (7.5625*(pos-=(2.625/2.75))*pos + .984375);
}
};
// BouncePast (new creation based on "EaseOutBounce")
Effect.Transitions.BouncePast = function(pos) {
if (pos < (1/2.75)) {
return (7.5625*pos*pos);
} else if (pos < (2/2.75)) {
return 2 - (7.5625*(pos-=(1.5/2.75))*pos + .75);
} else if (pos < (2.5/2.75)) {
return 2 - (7.5625*(pos-=(2.25/2.75))*pos + .9375);
} else {
return 2 - (7.5625*(pos-=(2.625/2.75))*pos + .984375);
}
};

/*
Gradual Transitions
*/
// EaseFromTo (adapted from "Quart.EaseInOut")
Effect.Transitions.EaseFromTo = function(pos) {
if ((pos/=0.5) < 1) return 0.5*Math.pow(pos,4);
return -0.5 * ((pos-=2)*Math.pow(pos,3) - 2);
};
// EaseFrom (adapted from "Quart.EaseIn")
Effect.Transitions.EaseFrom = function(pos) {
return Math.pow(pos,4);
};
// EaseTo (adapted from "Quart.EaseOut")
Effect.Transitions.EaseTo = function(pos) {
return Math.pow(pos,0.25);
};

That's all you need to do to add the transitions. To use them, simply add the transition to the effect, for example

transition:Effect.Transitions.Bounce

like here

new Effect.BlindDown(el,{duration:2, transition:Effect.Transitions.Bounce});

note that as some time is spent accelerating and decelerating the element, the animation will seem to "endure" less, it will seem to be faster, so it's better to at least double the duration time. Also I suggest tweaking the transitions parameters for further personalization.
As you can see skimming trough the code, the effects name (case sensitive) are: Elastic, SwingFromTo, SwingFrom, SwingTo, Bounce, BouncePast, EaseFromTo, EaseFrom and EaseTo.
Remember that if you upgrade your scriptaculous, you'll need to paste again this code at the end of the effects.js file. You could also consider adding it to your code, as it is not really as important where it is, as soon as the new transitions are loaded after the effects.js code. A third option can be creating a pennier.js file in the scriptaculous folder and change the script tag to add it, as an example

<script src="/lib/scriptaculous/src/scriptaculous.js?load=effects,pennier" type="text/javascript"></script>

but if you prefer to aggregate as much files as possible to reduce network delays during page loads, that's not you'll want to do.
Ah, if you use Flash and plan adding the tweening Pennier equations to your actionscripts, check out his book "Programming Macromedia Flash MX", part III:Dynamic Visuals, chapter 7:Motion, Tweening, and Easing. The book details are available on his website, where the chapter is freely downloadable here.
In a forthcoming article, I'll discuss about an animation library (the technical name is "tween sequencer") for Flash that incorporates the Robert Penner tweens, think of it as the scriptaculous for Flash: The FUSE Kit.

Ok, last time we examined the goods and bads of using Smarty, this time we'll install it.

First, make sure you got the right PHP version, it needs at least the 4.0.6. This can be seen by writing an empy page and writing in it, then calling that page.

Next, download the latest stable release from the smarty web site.

I prefer to have all my external libraries and programs in the /lib folder, I strongly racommend it, so decompress the source in the /lib/smarty folder.

I group all my site files in the /site folder, that's very useful too, so create a site folder and put a php file in it, let's call it page.php.

First line in you should configure and initialize smarty, then put your commands to produce some data, and at the end call smarty to output the data in the templates.

The reduced minimal sample is

<?
require ('/absolute/path/to/your/website/root/lib/smarty/Smarty.class.php');
$smarty = new Smarty;
?>

Keep an eye on capitals, as the code is case sensitive! This sample initializes adds the smarty code on top of your php file by inclusion. You'll need the absolute path to your smarty class, substitute as needed.

The smarty code defines a class, it explains to php what a "Smarty" is.
Second line actually defines a variable, called $smarty. This variable points to a new object called Smarty. An object is an "istantiation" of a class, speaking simple an "item" made by following the "instructions". You can have more than a Smarty object in a php file, but rarely you need to.
This Smarty item (let's call it object again and from now on) has properties (attributes) and can execute commands.

Now let's configure a thing or two. As I find it boring to always go checking out the document and site root and substituting, before going on let's write some code to autodetect this.

add this code on top

define('DR', $_SERVER['DOCUMENT_ROOT']);

Now the constant DR contains our document root, we can then modify the subsequent line this way:

require (DR . '/lib/smarty/Smarty.class.php');

each time you need the absolute path to your document root, you can refer to it by using DR.

Ok, this is all good, but if you load the script in the browser, it spits out a blank page.

What remains to do? Configure and execute some commands with the smarty object, of course! But before going on, I need to make a break for a security advice: templates doesn't "need" to be in your document root, they can stay everywhere, and it's highly suggested moving them outside this folder because they could be accessible from the web directly otherwise! Also, you'll need to set some permissions, if you're too loose it's possible you enable complete strangers to write their files everywhere, compromising your hosting server.

Now that I did some information technology terrorism, we can go on!

To give Smarty a command, you use the PHP syntax

$smarty -> command(argument [...]);

while to set a property we use

$smarty -> property = value;

We'll need to set up at least two directories, better three, and two of them should be writable by the web server (not the web users!).

So we create the /templates, /templates_compiled and /templates_cache folders, have templates_compiled and templates_cache writable (you can chmod them 770 from shell or even from the majority of the ftp clients, including the one in Dreamweaver!). Then we make smarty aware of the presence of these directories by adding these lines on bottom of the php file:

$smarty->template_dir = DR . '/templates';
$smarty->compile_dir = DR . '/templates_compiled';
$smarty->config_dir = DR . '/site';
$smarty->cache_dir = DR . '/templates_cache';

Perfect, and we added en passant the config_dir, that tells the Smarty object where to find auxiliary configuration files. We set it to the /site folder itself.

Now, to assign some templates variables, use this

$smarty->assign('firstname','Giancarlo');
$smarty->assign('lastname','Di Massa');

to load, parse and output a template, use

$smarty->display('page.tpl');

This will make the Smarty object go fetch the page.tpl file in the templates directory, so better have something here. Create a page.tpl file and put in it

Hi {$firstname} {$lastname}, how are you?

Save and reload the page.php file. It should output

Hi Giancarlo Di Massa, how are you?

Smarty substituted the two tags with the assigned variables in the page.php file!

If you are a programmer, go study the smarty syntax for programmers, it tells all the commands you can issue on the smarty object. If you're a designer instead, there is a list of all the tags you can use in the templates, you can edit them as if they were static HTML files sprinkled with "programmer's magic".

Most of the other template engines work the same way, for example the VlibTemplate or the RainTPL libraries.

One last word is about the MVC architectures. MVC stays for Model-View-Controller, is a way of separating content (the model) from the code (the controller) and the html (the view). A complete MVC system that takes care of all the aspects of data fetching and manipulation, from database queries to the output, is often called a framework. Smarty can be part of a MVC framework but it's not itself one. Some good PHP frameworks are CakePHP and Symfony.

I use a MVC framework I did myself called Presenza.

Next time we'll better organize our php code and start having something more complex of an Hello World template, so stay tuned.

Programming in PHP without separating content and code can lead to unwanted results, low mantainability and slower production. Even nowadays you can find tons of scripts written by filling HTML pages with chunks of code.

If you do that,

• Web designers with no programming skills will not be able to customize easily your script's appearance.
• If you want to change a site, for example a festivity or a redesign, you will need to face a big amount of work adding again all the PHP code to the new HTML pages.
• You will not be able to focus on the project because you'll have to manage yourself all the aspect of HTML production, from loops to file inclusion.

At my first web works I had these problems too. Building a new site required more work that I expected, because it was also difficult to reuse the code built for preceding customers. Then I started putting all my HTML in separate files, reading it with PHP and doing substitutions where needed. That was really better, I was able to change HTML when I wanted, but nothing more. Data that needed to be presented by "looping" the same HTML needed to be built in PHP, and in some situations I needed some sort of conditional programming in these so called 'template files'. I started to write a full fledged 'template engine' myself when a project saved me. I customized an e-commerce script for a project, and that script used an open source template engine. At first I was... how to say? Puzzled! As I looked over the template files I saw heaps of strange code.. it wasn't PHP so I tought that It was a really bad idea to push the things so further. Half of the script functionality lied in the template files themselves, and I was even a bit angry because I tought I had to learn a new language... inside the language!
But as I was changing the look and feel of that site, so was my opinion of that system. It's not bad after all... no, it's good indeed.. wait, it's great! I never went back and used that engine myself for all my other projects: it's name is Smarty.
Here are some interesting functions:

• You can edit the template files as if they are HTML documents and separe them from the code with a little effort, if you don't want to learn the Smarty language.
• Smarty language is much natural and template oriented than PHP, some things like iterate an array and outputting the same HTML code with the array data inside are very easy to do.
• You can include other files from your templates, these files will be parsed too.
• There's support for variables and constants
• You can produce a piece of HTML, then save it into a variable and reuse it later in the page, even modify it.
• You can put decisional code in the templates, do math operations and store results in new variables.
• Smarty has a plugin system with a very good repository, it's easy to write new plugins and they are autoloaded after you put them into their folder.
• Has an advanced cache system that builds already decoded chunks of templates for speed purposes, so you actually can go even faster than mixing PHP with HTML.
• There are many output buffering functions that give you abilities to change the whole page after it is generated and before is sent to the client, just for example you can with a single line change all your website and tell the system to add target="_new" to all external links.
• You can "skin" your site as you want, it's really possible to do a complete makeup of a whole web project in a day or two, even change skins in realtime!
• There's a template debugger to show data being passed to the engine!

So, by now you would think that Smarty is the best thing after chocolate milk, but it has some negative aspects worth exploring:

• All the HTML is sent at the same time, while with PHP you can send the page in chunks. However that required special attention when you wanted to set cookies, because these need to be sent before everything else.
• Smarty is written in PHP itself. A C++ templating engine maybe would be faster (there are some out there), but then you would need to write new plugins in C++ too. You use smarty by actually loading it entirely in memory each time you need to access template files. If you need to output really simple HTML code in little pieces of code, and these pieces are in separate pages, don't use it. Just an example, if your script just outputs "OK" after the computations, it's better to use echo for the text.
• You will need to learn a new language. It's simple and everything, but it's not rich as PHP itself, it's only a template language. The thing I miss more is the switch conditional construct, you need a series of if..elseif...elseif to emulate it. However this language is always used only to produce the presentation, you'll end up moving everything related to visualization to the templates, never using echo again if not for debug purposes.
• It's not always easy to upgrade an existing project to using a template engine.
• If you use an aggressive caching mode and make changes to the templates, those will not reflect online until you clean the template cache directory.
• Smarty adds memory to your requirements, better have a look at the PHP memory_limit setting.
• It has some good builtin plugins to produce drop downs listboxes, radio buttons and dates inputs in forms, but these elements require formatting the data in a certain way.
• If you dive other scripts directly into the page, some symbols, like the curly braces, can collide with Smarty, that will think you are initiating a template command sequence, so you'll need to surround these pieces of code with literal tags, that tell Smarty not to parse them.

As this argument is very long, I decided to cut it in parts. Next part will be about installing Smarty and starting using it. We'll also have a look at other template engines, and talk about full PHP frameworks that use the MVC paradigm, but don't worry about that right now.

I installed the package only once, because after that, I used the same setup over the next Windows installations, just copying the old directory. The package has a cool script that sets up the MySQL and Apache servers as system services and makes them start up at the computer boot (simply remember that this script needs to run with Administrator priviledges under Windows Vista).
As I didn't want to touch the preconfigured website (a nice panel that shows the working services, has examples of the various functionalities and a phpMyAdmin script) I ended setting up a virtualhost for each website I was working. Apache (the web server) has a function that makes you share multiple sites on the same machine and using the same web server. Every decent webserver today has these functions, Apache calls these sites virtualhosts.
In a production environment, you would set up each virtualhost with his domain name (I did so for my test server initially), but this meant each time you had to test the site, you had to be connected to Internet or set up a name server, because otherwise the system couldn't find the virtualhost. I assigned a different port for each server, starting from 81 (80 is the standard HTTP port) and going on. However, I suggest always use a port higher than 1024 for custom services like these, because the web server could collide with other services or use reserved ports.
Configuring these virtualhosts means creating a new folder that contains the site files (a new site root) and modify two configuration files (don't worry, they are explained in plain english, it's very simple), in the main file we tell Apache to start listening to another port, in the other file we add the virtualhost directive (some lines you always end up copy and paste and maybe customizing later).
As for simplification purposes I imagine you already downloaded and installed the LAMP distro, I personally use XAMPP (my installation folder is D:\xampp, because my OS stays in the C: drive and this way I don't have to move anything when I reinstall, adjust as you need, but I really recommend for a x:\XAMPP path).
Open D:\xampp\apache\conf\httpd.conf with a text editor, after the line

Listen 80

that tells the server to listen to port 80, add this

Listen 81

then scroll at the bottom, and before the last block

#
# Note: The following must must be present to support
# starting without SSL on platforms with no /dev/random equivalent
# but a statically compiled-in mod_ssl.
#
<IfModule ssl_module>
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
</IfModule>

add this two lines

# Virtual hosts
Include conf/extra/httpd-vhosts.conf

this tells the server to include a new text file in the configuration, where we'll put everything related to virtualhosts.
Next time we'll need to add a new virtualhost, in the main httpd.conf file we will only need to add a Listen 82, Listen 83, Listen 84 [...].
Now save, go in D:\xampp\apache\conf\extra and create this httpd-vhosts.conf file.
Add these lines

# Virtualhost domainname.com - port 81
<VirtualHost *:81>
DocumentRoot D:\xampp\htdocs\virtualhosts\domainname.com
ServerName localhost:81
</VirtualHost>

then save and exit. Ah, remember that domainname.com should be replaced with your site domain's, for example ebay.com or yahoo.com.
We're almost done, you just need to go to D:\xampp\htdocs, create here a virtualhosts folder (here well'put the document root of each of our virtualhosts) and in the virtualhosts folder put a domainname.com folder (replace with your site domain's).
If you want to be sure everything works, put a file called index.htm in the domainname.com folder and add this line in it

If you can read this, the domainname.com - port 81 virtualhost works correctly.

then save and exit.
Now stop and restart Apache (Administration Tools/Show local services in the Control Panel, find Apache2, click Stop, then click Start) and if everything is right, you will see the message wrote in the index.htm file by going with the browser to the url

http://localhost:81

Congratulations. And now? There are some optional steps you can make

• If you got a dynamic IP, you will need to set up a dynamic DNS service to bind it to a domain name. I use DynDNS, it's the most famous I think. You'll need to open a free account, add a dynamic DNS service. If your router natively supports dynamic DNS refreshes (has a dyndns client in the firmware) log on to the router, find the function, insert your dyndns domain, username and password, save and restart. If you're not sure, you'll need a dyndns refresh client you can find here.
• If you're behind a firewall, you will need to open the ports you are using.
• If you are using a router, you will need to use the port forwarding feature of the NAT to explain your router how to serve requests from outside.
• If you want to use MySQL, the default password is blank, that means everyone from outside will be able to read your test data. Not a big problem, but better change it using the phpMyAdmin script (located at http://localhost/phpmyadmin). While you're using the phpmyadmin script, add a database to each domain in the form domainname_com, so you can access it.
• The mail server has not a startup script yet, you will need to call it when you will need it. I created a shortcut to D:\xampp\MercuryMail\mercury.exe in my Quick Launch bar. When started, an icon will appear on the tray, double click it to bring the server control panel. I suggest you add a test POP3 account by clicking the Configuration menu, Manage local users, username test and password test. You will be able to add this mailbox to your email software.

Now your server is visible from outside, you got a database for each domain, you know how to add virtualhosts. What to add to the list? Really simple, you should make your PHP scripts server-aware!
This means having the remote, live settings and the test server settings on the same script, and having the script "detect" if it's running on a test server or on the live server.
You can do it this way:

$testserver = $_SERVER["SERVER_NAME"]=="localhost";
now if the $testserver variable is true, you use some settings, send email to the test account and so on.
Example:
if ($testserver) {
$dbuser = "root";
$dbpass = "";
$dbhost = "localhost";
$dbname = "domainname_com";
} else {
// your hosting provider's data
}

and if you use mail functions

if ($testserver) {
// mail to the 'test' account
} else {
// mail to the real user
}

To syncronize your test site with your live site, simply copy the virtualhost document root in a D:\sites folder (always do that! you will know exactly the state of the live server and it will provide a backup, do not load from the virtualhost document root!).
To load the MySQL database, export it to SQL and import it on the live server with the phpMyAdmin script of the hosting provider.