Hide full article
In recent TidBITS issues, I've been sharing my world view about software that makes Web pages. I started with text editors in TidBITS-384 and continued with visual editors in TidBITS-386. In TidBITS-387, I looked at GoLive's CyberStudio from the page building angle, but CyberStudio also includes site management features, and I promised to cover them soon in tandem with other competitors. First, however, it's time to check out Frontier, which offers a unique environment for Web publishing.
<http://www.scripting.com/frontier/>
Understanding Frontier -- Frontier 4.2.3 is a free, smart database. The software is free because UserLand Software founder Dave Winer decided to release it that way (see TidBITS-279); it's smart because it uses Apple events and a built-in scripting language (UserTalk) to control most anything; and it's a database because it stores information. Frontier is widely used in the Macintosh scripting community, and its users are often passionate about its merits, which include the ability to store components of a Web site and convert them into a complex, automated Web site.
<http://www.scripting.com/frontier/snippets/ features.html>
Exploring Frontier -- You begin exploring Frontier by opening its main table (called the "root"). The root contains entries, each having a kind and a value. For example, one such entry, named "readme," is of the kind "wp text" (word processing text), and if you double-click it, a window opens showing the text and a WP menu appears offering a few word processing commands. Web publishers using Frontier may create and store HTML in wp text entries elsewhere in the database.
Another category in the root, called "user", is of the kind "table" and double-clicking it opens another table filled with user-related items. For instance, one such entry, "organization," took on the value "TidBITS" when I personalized Frontier. Similar entries in other locations let you set how Frontier will publish Web pages. You can navigate Frontier by working through a large hierarchy of tables, or through an outline that reveals and hides different portions of the database.
The Key to the Treasure -- Table entries can also be "verbs," commands that are "called" in Frontier scripts. Using Frontier scripts, a capable scripter can automate most anything on a Macintosh, including other applications. Scripts can be run in different ways: from menus, by opening them in Frontier and clicking the Run button, or by typing their names into Frontier's Quick Script window. Or - to jump ahead of myself slightly - you can call them as you "render" a Web page.
Matt Neuburg, TidBITS Contributing Editor and experienced Frontier user, has commented that "Frontier is the command line to your Macintosh." The following four points are from his comments:
Frontier can drive the System and Finder. It can create, read, copy and delete files, set their types and creators, find out what time it is on your clock, read the clipboard, and more.
Frontier's functionality is available everywhere. It can put menus into other programs, and it can even make double-clickable pseudo-programs.
Frontier talks Apple events much faster than AppleScript does. If an application is scriptable, Frontier can drive it and ask it questions.
Frontier can receive Apple events, which means you can drive Frontier from other applications. Webmasters can use Frontier to process form requests sent in from people browsing Web sites. For instance, one of the top entries in the TidBITS search engine contest (see TidBITS-380) worked this way: Someone searching the TidBITS Web site clicks the search button, WebSTAR (the server software) talks to Frontier, Frontier consults a FileMaker database containing TidBITS issues, and - based what it finds in FileMaker - constructs a new Web page, which it gives to WebSTAR. WebSTAR then sends the page back to the browser.
Frontier's ability to automate most everything, combined with the hierarchical nature of its database, makes it a unique tool for Web publishing. If you use Frontier as a site management tool, you can work from the inside or the outside.
Working from the Outside -- Working from the outside is easier, because you don't have learn to become a competent Frontier user. To work from the outside, you use BBEdit (from Bare Bones Software) to create pages, but you employ the Frontier-created Sites menu in BBEdit to "render" the final site from the raw HTML created in BBEdit.
<http://www.barebones.com/bbedit.html>
It won't take long to learn the basics of rendering. When Frontier renders a raw HTML page (or group of pages) into a site, it employs a complex series of processes and filters that make (optional) changes such as:
Uniform top and bottom matter appears on each page.
Entities replace upper-ASCII characters in the raw HTML (a useful feature especially for people who write in languages like French).
Macros that call Frontier scripts are replaced by their results. (For instance {clock.now()} returns the current date as a result, and there's a script that inserts image tags with automatically generated height and width attributes.)
Email addresses and URLs convert to links.
Quoted text is replaced by an item in a Frontier glossary (yet another Frontier table). For instance, I might want "TidBITS" to be replaced by a link to the TidBITS home page.
If you work in BBEdit, you need not ever explore Frontier, and these features are readily available. If you choose to work inside Frontier, after you get set up, you probably could mostly work from BBEdit as well.
Working from the Inside -- You can use any software you like to create the raw HTML pages stored in Frontier, and then switch to Frontier to take advantage of Frontier's hierarchical approach. Frontier stores each HTML page as a table entry. When you render a site, those entries become separate Web pages, organized in a folder structure that mirrors the structure used in Frontier.
(I've simplified a lot in the paragraph above- rendered pages can be constructed from scripts, or from "outlines." Scripts can assemble pages from most anything you've created or scripted, and outlines have many uses, but I'm not going to delve into them in this article.)
However, using Frontier's hierarchy goes much deeper. For instance, you can have more than one Frontier glossary, and Frontier replaces quoted text based on the glossary located closest to the raw HTML file. (If the glossary isn't in the same table as the raw file, Frontier looks up one level, and keeps looking up one level until it finds a glossary.)
Hierarchies also play a big roll when you use "directives." A directive is a table entry that notes how you want to handle a general aspect of a group of Web pages, such as the background color. A directive can also be placed directly in a raw HTML file. When a raw HTML page renders, directives defined inside it always take precedence. But, if a directive is not defined, the page looks in and up the hierarchy for a definition. Using directives, it's easy to give one branch of a site an orange background and another a green one.
My brain starts to hurt at this point, so rest assured that I've but rippled the surface here. I haven't mentioned templates, the ability to include one file inside another, or the ability to create an HTML-ized site outline. Templates are an especially key feature, and I leave them as an exercise to interested readers.
Rendering -- When a page renders, several filters and processes take place, including running any macros that you've stuck inside it (or its template). This has millions of uses.
As an example, take the new TidBITS home page, which regenerates every hour. Each time the page regenerates, it gets a new, automatically assembled graphic. The new graphic has one of several slogans and a callout to an especially interesting article (or group of articles) that you might want to read. The graphic uses a client-side image map, so new HTML must be created for each new version of the page. Although Geoff Duncan did the work in AppleScript and HyperCard, Frontier could also do the job.
As another example, consider this note from Pam McAllister <pmcallister@pugetsound.org>:
I started using Frontier a few months ago. It took several days to learn the system and import my sites, but now I can handle updates and additions in a fraction of the time it took before. I've added many features, such as indexes of parts of the site, that I would never have time to do manually. I also wrote a Frontier script that puts all the pages into a FileMaker database, which is then searchable on the Web site (using Lasso). Even as a novice scripter, that project took only a few hours. [Check out the SoundWeb site for an example of what Pam has been working on.]
<http://www.pugetsound.org/>
<http://www.blueworld.com/lasso/>
Complexity -- Learning Frontier reminded me of the Far Side cartoon where a student asks to be excused from class, saying that his "brain is full." My ascent up the learning curve was facilitated by an online tutorial created by Matt Neuburg.
<http://www.scripting.com/matt/webtutorial/>
(Matt is currently under contract with O'Reilly Associates to write the first book about Frontier. The book should come out in tandem with the upcoming release of Frontier 5.)
Is It for You? To summarize, Frontier's structure makes it easy to organize HTML pages created in other programs (or in Frontier, though the tools are limited). Once your site lives in Frontier - if you set things up correctly - it's easy to move pages or other resources within the database and to change elements that appear on multiple pages. It's also possible to create Next and Previous links throughout a collection of pages that will be navigated serially. Sites can be rendered to a local folder or via FTP to a remote site. You can render by page, by table, or by what's changed since you last rendered. Frontier is a natural at page rendering that requires automation, especially if multiple applications must work together.
Frontier is pleasant enough to work in, but whether it's worth the time investment to learn depends on the nature of the site. About halfway through my research for this article, I thought Frontier's seemingly boggling array of tables needed an nice user interface badly. A day later, though, it seems accessible and useful. However, if I hadn't already had a good understanding of hierarchies, HTML, macros, and general scripting terms, I would have given up. Further, it's difficult to remember how to use Frontier for running a Web site because the commands aren't obvious on the menus and in the dialog boxes.
You can import a existing site into Frontier, but you must recreate a lot of work by hand to take advantage of Frontier features. Frontier also lacks a few features that you might require. There's no visual view that shows how pages and resources relate to one another, using a spider's web or organizational chart analogy. There's no tracking mechanism for noting which pages are done or who's working on them. Creating unbreakable relative links in Frontier requires working with macros, whereas in other programs, you just drag a picture representing the link destination to the link source. Frontier also lacks a site-wide Find-and-Replace command and spelling checker, as well as a link checker and an HTML checker/validator, though I'm confident that knowledgeable Frontier users can work around those limitations by integrating Frontier with other applications.
Next time, I'll return to the site management features in CyberStudio and also look at other site management software.
