Up and Running with Frontier Web Site Management
by Matt Neuburg
Author of the book Frontier: The Definitive Guide

Prev | TOC | Next


Frontier HTML Basics, and the Directive Hierarchy

Frontier-generated HTML

Let's use our browser's ability to display the source of a page to examine the HTML that was actually generated in order to give the results we just viewed in the browser. It looks something like this:

<html>
<head>
<title>Welcome!</title>
<meta name="generator" content="Frontier 5.0 Win95"></head>
<body  bgcolor="#000000" alink="#008000" vlink="#800080" link="#0000FF"
text="#FFFFFF"><p>
   
<b> Welcome!</b><p>
   
This is my Web site. I hope you like it here.<p>
   
<b> Notice.</b><p>
   
This Web site is under construction. But, thanks to Frontier, 
constructing it will be very easy!<p>
   
</body>
</html>

Frontier has generated structural tags, including a <body> tag with our designated color parameters. That's fine because those are things every Web page in the known universe has to have.

But Frontier has also supplied <p> tags before each of our double-returns, and has introduced <b> and </b> tags based on our use of triple-asterisks; this allows you to get up and running very quickly, but on the whole it is not typical of what Frontier does.

Generally speaking, Frontier is very sparing about the way it interferes with your HTML. Frontier does not usually try to generate formatting HTML for you (such as <p> and <b>) except in fairly specialized situations. The first two lines of the original text, the ones about #autoParagraphs and #clayCompatibility, were responsible for Frontier's making this kind of HTML here; whether you use these features is going to be a matter of personal preference.

Directives

Let me explain about those two lines. First of all, notice that they begin with "#". This should remind you of the entries in the myFirstSite table that begin with "#". In fact, they have the same status. Such lines are called "directives".

For the most part, directives work the same way whether they are table entries or lines in a Web page, except that in a Web page the argument (the value for the directive, which follows it on the same line), if it is to be understood as a string, must be in quotes, whereas in a table it must not, because in a table the fact that it is a string comes from the Kind column for that entry.

There is a simple, yet powerful, hierarchy of directives. The top level is actually in a table we haven't looked at yet, user.html.prefs -- open and examine it now. Here, none of the directives have "#" at their start; nevertheless, these are directives. The hierarchy works as follows:

Okay, that's the hierarchy. But how is it actually used?

We have already taken advantage of the directive hierarchy, without even noticing it, in rendering our default page.

For example, you may have noticed that in user.html.prefs, autoParagraphs and clayCompatibility were both set to false. But we wanted them to be true; so we set them within our Web page, overriding the general settings for that one page only.

Here's another example. You may recall that, back when we rendered websites.samples.randomStuff, the #template inserted all sorts of information, with your name and email address and the date at the top, and similar material at the bottom.

That #template was websites.#template, so any Web page inside the "websites" table at any depth ought to use it; yet websites.myFirstSite.default evidently lives inside websites, but did not use this #template when it was rendered -- why not?

Because inside websites.myFirstSite is a different #template, and this is the template that was actually used.

There's one more little thing you might like to be clear about before we go on; the #prefs table is special. There is no #prefs directive; the only purpose of the #prefs table is to give you a place to locate directives conveniently in a table. By keeping directives in websites.myFirstSite.#prefs, we keep them from proliferating in websites.myFirstSite. But the effect is the same as if they were in websites.myFirstSite.

Also, a special rule says that entries in #prefs don't have to have names that start with "#" -- because a directive is the only thing that's allowed to live in a #prefs subtable, so there's no possibility of confusion.

Applying the directive hierarchy

Thinking about the directive hierarchy, we start to realize how powerful and flexible Frontier is. You organize your site according to the common aspects of pages.

Suppose you want all pages in your Web site to have a white background color, except for one which is to have a green background color. You put a #bgcolor directive in your site table that sets a white value, but in the text of that one page you put a #bgcolor directive which has a green value.

(Note: actually, you'll probably put a bgcolor entry in the #prefs subtable of your site table. But since this is the same as if you had put a #bgcolor entry in your site table, and since it is easier to identify a directive if its name starts with "#", I'll just talk as if the #prefs table didn't exist.)

All right; now suppose you want all pages in your Web site to have a white background color, except for three special ones which are to have a green background color: then you put a #bgcolor directive in your site table that sets a white value, but put those three pages together in a subtable of your site table, with a #bgcolor directive in that subtable which has a green value.

To see the directive hierarchy in action, go into websites.myFirstSite and select the whole "default" line (in selection mode, not content mode), Copy it, and immediately Paste it, electing to create a duplicate, which will be initially called "default #1"; rename it to "default2". Open "default2" for editing, and at the start insert a line:

#bgcolor lightgrey

Now choose Preview Page. The browser shows the page as having a light gray background. "default2" is getting its background color from the directive inside itself, overriding the setting in myFirstSite.#prefs; but it inherits the white color of the text from myFirstSite.#prefs, since it has not overriden it inside itself.

You may delete "default2" now.

Minding your <p>s and <b>s

Now, to return to the #autoParagraphs and #clayCompatibility directives.

The #autoParagraphs directive governs whether Frontier should insert <p> wherever it sees two returns in a row (it inserts it before the two returns).

The #clayCompatibility directive (the odd name comes from an earlier Frontier-related project, ClayBasket) governs whether Frontier should surround with <b> and </b> tags every line that begins with "***" (removing the "***").

On the whole I don't use these features of Frontier all that much, but every once in a while they do come in very handy; we certainly profited from the ability to turn them on for one page in myFirstSite.default, since we were able to create a page without typing any HTML ourselves.

But now, as an experiment, go into myFirstSite.default and remove the #autoParagraphs and #clayCompatibility lines. Preview the page in the browser. The text is interpreted literally, as a single paragraph.

Now let's put in our own HTML instead; change myFirstSite.default so that it says:

#title "Welcome!"
<h2>Welcome!</h2>
<p>This is my Web site. I hope you like it here.</p>
<h2>Notice.</h2>
<p>This Web site is under construction. But, thanks to Frontier,
 constructing it will be very easy!</p>

Preview this in the browser.

The HTML we typed into myFirstSite.default is untouched; it is passed along to the browser, which obeys it to give the desired formatting. So you can either put in your own <p> and </p> tags or you can have Frontier put in <p> tags for you. You should not combine the two methods! If you do, you could end up with some fairly skanky HTML.

The #title directive

The other directive we just saw operate is the #title directive. Frontier uses the value of this to create a <title> tag for you, and this shows up in the titlebar of your browser's window when you preview the page.

The #title directive works hierarchically too, although you can't have a "title" entry in your user.html.prefs table (you can but it does nothing). Still, it would be unlikely that you would want the same title for multiple Web pages -- in fact, we will see later that this would cause some features of the Web site management system to break.

So the usual use of #title is inside each individual Web page.

But here's a little trick I like to use, taking advantage of the hierarchical nature of directives; in websites.#prefs I put a title directive that says, "Hey, NO TITLE!!!!" That way, if I forget to add a #title directive in a Web page, I see "Hey, NO TITLE!!!!" in my browser's titlebar when I render the page, and am reminded.

Directives come first

Just a couple more things about directives. In a wptext Web page such as myFirstSite.default, to be seen as a directive by Frontier, the text that begins with "#" must come absolutely first in its paragraph. Each directive must be a paragraph of its own.

And, you can save Frontier a lot of work (and yourself a lot of time) if all your directives come first, at the beginning of each page. To let Frontier know you've done this, the #directivesOnlyAtBeginning directive is set to true. In response, when it renders the page, Frontier stops looking for directives in a wptext as soon as it hits a paragraph that doesn't begin with "#".

This feature can bite you, though, if you don't watch out. If #directivesOnlyAtBeginning is true (as, by default, it is), then if you accidentally insert a blank line in a wptext Web page before the directives, none of those directives will be obeyed (and they will show up in the final HTML).

All in your <head>

This section is for HTML experts who want to know how to get more control over what goes into the <head> region of the HTML. Beginners, and those who don't know that what's in the <head> region has any significance, can go on to the next chapter.

There is a directive #includeMetaCharset, which determines whether a <meta> tag should be included saying what character set we are using. It comes set to false in user.html.prefs, and I tend to leave it that way.

Another directive is #includeMetaGenerator, which determines whether a <meta> tag should be included saying that Frontier made this Web page, and on what platform; you can see from the HTML we generated from myFirstPage.default that this comes set to true.

You can insert into the <head> region a single block of material consisting of anything you like, by setting the #meta directive. Despite its name, this directive doesn't generate a <meta> tag; if that's what want, you have to include it in the directive's value.

On the other hand, there is also a clever, flexible mechanism for adding <meta> tags of generalized name/content form. For instance, to end up with a <meta> tag that looks like this:

<meta name="author" content="Matt Neuburg">

you define a directive #metaAuthor whose value is "Matt Neuburg". This works for any #metaXXX directive you care to invent; a <meta> tag whose name value is "XXX" will be created.

Similarly, to end up with a <meta> tag that looks like this:

<meta http-equiv="expires" content="31 Dec 99">

you define a directive #metaEquivExpires whose value is "31 Dec 99". Again, just modify this for any desired #metaEquivXXX.

Finally, there is a #javascript directive. This is a somewhat advanced topic, but here's a very quick sketch: typically you'll keep your javascript script in a wptext or outline, and set the value of the #javascript directive to a string version of it. So, for instance, if your javascript script lives in workspace.myJavaScript, then the value of #javascript would be string(workspace.myJavaScript).


Prev | TOC | Next

All text is by Matt Neuburg, phd, matt@tidbits.com.
For information about the book Frontier: The Definitive Guide, see my home page:
http://www.tidbits.com/matt
All text copyright Matt Neuburg, 1997 and 1998. ALL RIGHTS RESERVED.
No one else has any right to copy or reproduce in any form, including electronic. You may download this material but you may not post it for others to see or distribute it to others without explicit permission from the author.
Downloadable versions at http://www.ojai.net/matt/downloads/webTutorial.hqx and http://www.ojai.net/matt/downloads/webTutorial.zip.
Please do not confuse this tutorial with a certain other Frontier 5 tutorial based upon my earlier work.
This page created with Frontier, 2/11/2000; 6:59:53 PM.