Eileen -- don't try to make it harder than it is! One comparason was to think of the tags as "SSI" calls. You write your HTML page, and the "tags" insert the missing data on processing, and then output the page.
It's a two step process.
You design the basic site using the w3tvars & w3t_themes files, and modifications to the templates where necessary.
The next step to increase the tweaking you can do, is to edit what is put in the SSI call (the tag value).
It's a cookie cutter or puzzle. You use the "template" to tell the program where to stick the values, and how you want them to look.
You still need the program to fill in the values.
The "values" in perl can be large chunks of code! They don't have to be small. Perl is a text processing language, and for example, on the links site, the entire page of links listings is stuffed into a tag called %Links% and you build the page (for example on my site) inside a table for formatting (graphically, since the forum doesn't like braces):
------------------------
| %header% |
------------------------
| %links% | %sidebar% |
------------------------
| %footer% |
------------------------
.
The %links% tag contains nested tables, and on average 25 links. That is all inserted into the "layout" with a small tag! Makes page design and maintennance very, very simple, and allows HTML designers to leave the programmers alone :)
The %links% tag is built from a loop of calls to the individual link template for each link, and then they are all stuffed into an
$OUTPUT{links} .= result_of_each_link_template;
In this way, it's much, much easier to build complicated sites, by building different building blocks at different levels, but at the "page" level all you do is assemble them.
If the structure of a link, or number of links, or even what a link is, changes, it doesn't matter to the page template. It inserts those values. (It's up to you to determine whether each sub-template is a complete item ie: full table, or full table row, or if it is a part of a table or row, etc. I've tended to chose where possible to make sub-templates whole tables, except where they are OBVIOUSLY a table row --- such as a FORUM-LINE which is a line in the FORUM-TABLE which is the list of tables. But FORUM-TABLE would be a "whole" item, that is inserted into the MAIN-TABLE page of the site, inside a TD set of tags. In otherwords, the top template is a "complete" item, and each of the blocks that fit in are complete items, so there is no overlapping HTML. But, this is a design thing, and everyone has their own preferences.)
The real trick is not to make it too complicated. The first release of something like this is a learning effort for both the programmers and the users, and subsequent releases will streamline and fix logic problems (and this program gets lots of regular updates!)
Just remember, what you stuff into an $OUT{xxxx} variable becomes a %TAG% in the template, and the template parser inserts the contents of that tag/variable at that point in the file.
Each formattable item/object is worth having a template, even if it's only a few lines of code long, since it makes fixing, and assembling larger, more complext objects, such as a complete table, or a page containing several tables, much easier :)
I haven't looked at the "guts" of how this template parser works, but the effect is the same as the programs I've been using.
I hope to get w3t and Links SQL integrated (there is already a shared user database link being worked out), so that one site registration will let a user use the forum, mail, links, etc all through a site.
I've been supporting Links SQL for over a year now, and now that w3t is using templates, I'll be popping in more here 
I honestly couldn't afford the time to work with w3t until it used templates. This is why I chose w3t over UBB (it was much easier code to decipher) and now with templates, it will rock Less time will be spent by people trying to update/upgrade the program, and more time studying and enhancing it :)
