Typical Uses (Practical mod

D.3. Typical Uses

A typical use of the Template Toolkit is as an offline tool for generating static web pages from source templates. This alone can be invaluable as a way of consistently adding standard headers, footers, menus, or other presentation elements to all of the pages in a web site.

The ttree utility, distributed as part of the toolkit, can be used to automatically process an entire directory tree of files in this way. Rather than creating and maintaining web pages directly, you write your pages as source templates and use ttree to run them through the Template Toolkit and publish them to a new location, ready to be viewed or accessed by your web server. During this process, any directives embedded within the templates are interpreted accordingly to build up the final HTML content. This can be then be combined automatically with any other standard page elements or layout templates before the output is written to the destination file.

You can also use the Template Toolkit in CGI scripts and mod_perl handlers for generating dynamic web content. The Template module provides a simple programming-level interface to the template processing engine and allows you to cleanly separate your application code from presentation logic and layout. It provides a rich set of bindings between Perl data and code in the backend and template variables in the frontend. That means you can call into templates from your Perl code and also call into Perl code from your templates. You can freely pass all kinds of Perl data between the front- and backends, in the form of scalars, hashes, lists, subroutines, and object references, allowing you to hide all manner of internal complexity behind a simple data interface. This makes it easy for you to perform all sorts of technical wizardry in your templates, without having to directly expose or embed any of the Perl code that makes it happen.

The Template Toolkit includes a number of standard plug-in modules that provide various useful add-on functionalities. These include modules for creating HTML tables; fetching CGI parameters; parsing and processing XML, POD, and LaTeX; accessing databases via DBI; manipulating dates; processing URLs; and generating graphics, to name just a few. It's also trivially easy to load and use other existing Perl modules. If CPAN doesn't have what you're looking for, you can always implement your own custom functionality as a Perl module, which can then be loaded into the Template Toolkit for use and reuse as required.

This approach makes your code and your templates much easier to develop and maintain. If the people working on Perl application code are different from those who develop the HTML pages, it allows them to work on their separate areas without getting in each other's way. Even if you're the one doing all the work, it allows you to better separate the tasks and wear just one hat at a time. When you're wearing your application developer's hat, you can concentrate on the Perl code and making it work right. When you're wearing your web page designer's hat, you can concentrate on the HTML markup and making it look good.

It also makes your backend code and your frontend templates more reusable. You can have the same backend code running behind multiple sets of frontend templates, ideal for creating different versions of the same web site localized to spoken languages or customized to different users' requirements. You can also reuse the same set of templates in front of different backend applications, CGI scripts, and mod_perl handlers. Common elements such as headers, footers, and menus can be encoded as templates and then shared between your static pages generated via ttree and your dynamic pages generated online. The result is that you get a consistent user interface and presentation style for all your pages, regardless of how they're generated.