[OS/2 e-Zine! - Now on CD (Click here).]

Building Dynamic Web Sites in OS/2- by Chris Wenham

Part 2

Soon after Part 1 of this series was published I received a couple of e-mails pointing out the existence of other HTML Preprocessors for OS/2. One is Orb, a cross-platform preprocessor available for DOS, OS/2 and Solaris. Another is the Advanced Web Editor - an HTML editor with built in support for adding an HTML preprocessor. I didn't have time to look at these closely enough to talk about them this week though.

In this article I'll step you through the task of creating two web pages that have the same content, but represent two different varieties: One with lots of gee-gaws and widgets and Netscape optimizations designed to impress the socks off your boss, and another optimized for Lynx or other unsophisticated browsers.

I'll be honest up front and say that it is your job to figure out what those gadgets and gee-gaws are and how they're implemented. I see plenty of people have already figured out how to make ghastly monstrosities without my help, and there's always Builder.Com. My job is to show you how to manage that beast, once created.

We'll do this by making two templates, one for each design. The preprocessor will do the work of filling the templates with the real content for you, so you don't have the chore of making the same alterations in two different files at the same time. By the end of this you'll only need to edit one file and double-click an icon to make the changes globally. If you've ever used the mail merge function of your word processor, then you'll already be familiar with the concepts we're dealing with here.

I should make it clear that the technique of using a preprocessor is really only useful if the content of the page in question is going to change a lot, or is one of a series of pages that need a common design. If you're making a personal web page with photos of your cat, maybe you shouldn't bother with all this fuss.

Three Steps

The job of making the templates is divided into about three steps, which are:

  1. Make a prototype, using a sample of the content you're packaging
  2. Identify what's content and what's part of the page's design or structure.
  3. Snip out the content, replacing it with markers.

The first step is easy enough, just grab an HTML editor of your choice and make your two versions of the page with a sample of the content you'll be using. At this point it doesn't really matter what you use in the production, Homepage Publisher, e.exe, or (the more evil) FrontPage, just as long as the HTML code it saves is readable enough for you to work with it later.

When you save the files, put them in the same directory (a nice new empty one is good) but with names that reflect what version they are, like "example-p.it" for the plain version, and "example-e.it" for the enhanced one. The ".it" extension stands for "Internet Template" and doesn't really belong to any formal specification. You could use ".template" if you want and you're working on an HPFS partition. It won't make any difference to the preprocessor, but it will make it easier to tell at a glance what kind of file it is.

In the second step you'll identify what part of the page will be changing regularly and needs to be identical in each version, i.e.: the real content. If it's a bulleted directory of links or list of headlines then it's probably whatever appears between the <UL> and </UL> tags. If it's an essay then it'll be whatever's between and including the first and last paragraphs of it. In our example we'll assume it's a news page, with news bursts separated by a bulleted list. It might look something like this:

Tuesday June 21st, 2008. 5:45pm. Visa Micropayment: $0.85. Outside Redmond, WA: $6.00

Questions, comments and pizza may be delivered to news@newsburst.news.

This is our "plain" and Lynx friendly version. The enhanced version is far too evil to include here.

What we can see easily are the areas of volatile content that need to be separated from the page's structure. There's:

In our prototype, now opened up in a text editor (or at least an HTML editor that can work on the code level and won't mess up any of our special tags,) we locate these elements and replace the sample data we used in the prototype with some place marker tags. These tags themselves look a bit like this:

<$TitleImage>, <$VisaPrice>, <$ORPrice>, <$Headlines> and <$Feedback>

The dollar sign ($) beginning each tag is important, but doesn't have anything to do with money. It tells our preprocessor that it's a custom designed tag that needs to be dealt with. Otherwise it'd ignore the tag and assume it's part of the HTML specification.

After going through step 3 of the process, finding the content that our tags correspond to and replacing it with them, we have a complete template ready for use:

#include STANDARD.IT
<TITLE>News Bursts</TITLE>

<p><img src="<$TitleImage>" alt="News Bursts">

<p><?CompileTime>. Visa Micropayment: <$VisaPrice>. Outside Redmond, WA: <$ORPrice>

#include <$Headlines>

<p align=center>Questions, comments and pizza may be delivered to <$Feedback>


In strong emphasis you can see where I've snipped out the sample data used to build the prototype and substituted it for the place markers instead. You'll also notice the two "#include" lines, one at the top and one halfway through, and a <?CompileTime> tag. I'll get to those later, although you're probably smart enough to have figured most of it out already.

Working with the "Netscape enhanced" version will probably be a little harder, since there'll be a lot of other code getting in the way. But if you know what sample data you used when building the prototype you should be able to search for and find it easily. Remember, only replace that which you know is the real content, not any surrounding tags that are part of the template's structure. For example, don't delete the <UL> and </UL> tags when replacing the headlines section with <$Headlines>.

As you can also see from the example, it's safe to nest our place holders in the middle of other tags, as can be seen in the IMG tag. The HTML preprocessor is like a big automated global search and replace engine; location of the tags doesn't matter, and they don't have to be surrounded by spaces. You can build filenames out of them (imagine linking to a page with "http://www.yourdomain.com/<$MajorCategory>-<$MinorCategory>/<$Product>.html") and get as creative as you like.

The "#include" lines tell our preprocessor to include the contents of two different files. This is very important because the first one tells the preprocessor what all those custom place holders mean, and the second one imports the bulk of the content itself. The first one, STANDARD.IT, looks like this:

#define TitleImage title.gif
#define VisaPrice $0.85
#define ORPrice $6.00
#define Headlines headlines.txt
#define Feedback news@newsburst.news

And the second one, first pointing to <$Headlines>, which as we can see above resolves to "headlines.txt" contains this:

<LI>Life discovered on Mars, not interested in Windows. Extermination plans commence.
<LI>Grand High Poobah of Quadrant 18 acquires Dogs Playing Poker for $30 million.
<LI>Trafficking of illegal "Tickle Me" Beanie Babies on the rise.
<LI>Wired Magazine swimsuit issue hits the stands.
<LI>8th attempt to clone Walt Disney using DNA extracted from cells of cryogenically stored "father" successful. Clone expected to resume helm of media empire in 2009.
<LI>Self named "Equality 0-0001" wins seat on Congress for the Collectivist Party. Lays out plans for new world order by 2112.

Ah ha! Now we start to see where our content has been moved to. The STANDARD.IT, as its name implies, contains standard data such as the title image, prices, feedback address and the name of the file with all the headlines in it. It could also contain lots of other definitions not used in that particular template, such as animated GIFs and gadgets for the enhanced page. Anything #DEFINEd that isn't used in the template will simply and harmlessly be ignored, so definitions for fancy graphics intended for the enhanced version won't cause any problems when you use the same file to make the plain version.

These two #INCLUDE lines are also present in the gadget-enhanced version of the page too, once you've turned it into a template, since the content is all the same.

By now you might be noticing the simple syntax of those #DEFINE statements. It's just:

	#DEFINE Keyword_name Keyword value.
You'll see that the Keyword name must be all one word, with no spaces or tricky characters like quotes. It also doesn't need the brackets ("<" and ">") or the dollar sign ($). The Keyword value, however, can be many words and symbols, as long as it all fits on one line.

You've also probably guessed the purpose of <?CompileTime> too. It's a special internal tag, or macro, to the preprocessor that gets substituted with the full date and time that the page was built. It's designated with a question mark (?) instead of a dollar sign ($) to separate it from user defined tags. There are more such tags as these, but we'll get to them later.

Putting it into practice

You now have your templates all defined. You have one version that's decked out in the most vile, evil, gratuitous whiz-bang plug-ins and applets and Javascript and whatnot that your miserable mind can conceive. You've got hit counters, you've got drop down menus, you've got style sheets and animations and mouse rollovers and everything. It's the bee's knees. The wasp's nipples. Your site is it! But it's also inhospitable to any living creature on Earth, so you have a tame version too. It's low on graphics, it doesn't use any nested tables, and it takes about five seconds to load.

With the magic of the preprocessor you're maintaining two different versions of the same page, but you're only editing one file. But which file? Headlines.txt of course! It's usually best to edit this in a plain text editor, so the contents aren't messed around by superfluous tags inserted by well meaning WYSIWYG editors and word processors.

If you insist on editing it in a word processor that saves in HTML format, open it in a text editor later and snip out all the extra tags it puts in, such as the <HTML>, <TITLE> and <BODY> tags etc. This is because the word processor is expecting it to be a stand-alone page rather than something included in a larger design. A bit of a pain, yes, and a bit purpose defeating. But in a later column I'll show you a simple program that strips them out for you and prepares a page for simple, clean inclusion into another.

The last step, and almost neglected in this article, is running the template through the HTML preprocessor itself. As described in Part 1 of this series, you open a command prompt, change to the directory that you saved all your files to, and type:


It'll search for any file that ends in .it (example-p.it and example-e.it), processes them and saves the results as example-p.html and example-e.html. With the title, date, prices, headlines and everything all in their proper places, as set by the templates. All you have to do is upload them to the server. To simplify this step even further, create a program object on your desktop that runs the same command. Now you just have to edit the headlines file and double click on the icon. Easy peasy.

In Part 3 I'll start explaining how to use this to build a simple catalog site, using a "poor man's database".

(Editor's Note: Since the HTML Preprocessor by Dennis Bareis is updated so frequently, many people have written to tell us the link in last month's article was no longer functional. We have included a new link below to the page on which the file is located.)

* * *

HTML Preprocessor

by Dennis Bareis
download from Dennis Bareis's home page (ZIP, ~100K)
Registration: Freeware

Chris Wenham is the Senior Editor of OS/2 e-Zine! -- a promotion from Assistant Editor which means his parking spot will now be wide enough to keep his bicycle and a trailer.


[Our Sponsor: Indelible Blue - OS/2 software and hardware solutions to customers worldwide.]

Copyright © 1998 - Falcon Networking ISSN 1203-5696